The existing value of 0x1000 sets the IXE bit (Inexact floating-point exception
trap enable), but we really want to be setting IXC, bit 4:
Inexact cumulative floating-point exception bit. This bit is set to 1 to
indicate that the Inexact floating-point exception has occurred since 0 was
last written to this bit.

Reviewed By: kongyi, peter.smith
Differential Revision: https://reviews.llvm.org/D98353

As readnone function they become movable and LICM can hoist them
out of a loop. As a result in LCSSA form phi node of type token
is created. No one is ready that GCRelocate first operand is phi node
but expects to be token.

GVN test were also updated, it seems it does not do what is expected.
Test for LICM is also added.

This reverts commit f352463a.

Instead of setting mcpu like the previous bots,
set the target triple.

Each config builds either Arm only or Thumb only
code. This gives us some coverage of thumb specific
issues.

The new agents on Linaro's side are running on v8 hardware
so will report arch "armv8l" just like the v8 bots.
(and buildkite can choose any of them for v7/v8 jobs)

Reviewed By: #libc, curdeius, Mordante

Differential Revision: https://reviews.llvm.org/D98019

This patch optimizes the codegen for INSERT_VECTOR_ELT in various ways.
Primarily, it removes the use of vslidedown during lowering, and the
vector element is inserted entirely using vslideup with a custom VL and
slide index.

Additionally, lowering of i64-element vectors on RV32 has been optimized
in several ways. When the 64-bit value to insert is the same as the
sign-extension of the lower 32-bits, the codegen can follow the regular
path. When this is not possible, a new sequence of two i32 vslide1up
instructions is used to get the vector element into a vector. This
sequence was suggested by @craig.topper. From there, the value is slid
into the final position for more consistent lowering across RV32 and
RV64.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D98250

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D98399

There is no need to check for enabled pragma for core or optional core features,
thus this check is removed

Reviewed By: Anastasia

Differential Revision: https://reviews.llvm.org/D97058

Forward references to blocks lead to `Block`s being allocated in the
parser, but they are not necessarily included into a region if parsing
fails, leading to a leak. Clean them up in parser destructor.

Reviewed By: rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D98403

Add simplification of smul.fix and smul.fix.sat according to
  X * 0 -> 0
  X * undef -> 0
  X * (1 << scale) -> X

This includes the commuted patterns and splatted vectors.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D98299

Do constant folding according to
  posion * C -> poison
  C * poison -> poison
  undef * C -> 0
  C * undef -> 0
for smul_fix and smul_fix_sat intrinsics (for any scale).

Reviewed By: nikic, aqjune, nagisa

Differential Revision: https://reviews.llvm.org/D98410

This restricts the attributes to integers for constants of type
IndexType. So far an attribute like StringAttr as in

  %c1 = constant "" : index

is valid.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D98216

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D97443

Reviewed By: Quuxplusone, EricWF, #libc

Differential Revision: https://reviews.llvm.org/D97911

Two tests failed for some reason, need to investigate:
  https://lab.llvm.org/buildbot/#/builders/109/builds/10399

This reverts commit ad9e98b8.

Need to revert ad9e98b8 which this
commit depends on.

This reverts commit f771ef7b5f0ed260d00931cd50e6fe462edbacaf.

Since D86233 we have `mustprogress` which, in combination with
`readonly`, implies `willreturn`. The idea is that every side-effect
has to be modeled as a "write". Consequently, `readonly` means there
is no side-effect, and `mustprogress` guarantees that we cannot "loop"
forever without side-effect.

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D94125

The update_test_checks script can now check for global symbols and is able
to handle them properly when they differ across prefixes, e.g.,
attribute #0 might be different in different runs.

This patch simply updates all the Attributor tests with the new script.

Reviewed By: sstefan1

Differential Revision: https://reviews.llvm.org/D97906

Reviewed By: grokos, tianshilei1992

Differential Revision: https://reviews.llvm.org/D96444

The shuffle idiom is differently implemented in our supported targets.
To reduce the "target_impl" file we now move the shuffle idiom in it's
own self-contained header that provides the implementation for AMDGPU
and NVPTX. A fallback can be added later on.

Reviewed By: tianshilei1992

Differential Revision: https://reviews.llvm.org/D95752

Nested `omp [begin|end] declare variant` inherit the selectors from
surrounding `omp (begin|end) declare variant` constructs. To stop such
propagation the user can add the `disable_selector_propagation` to the
`extension` set in the `implementation` selector.

Reviewed By: tianshilei1992

Differential Revision: https://reviews.llvm.org/D95765

If we have nested declare variant context, it doesn't make sense to
inherit the match extension from the parent. Instead, just skip it.

Reviewed By: JonChesterfield

Differential Revision: https://reviews.llvm.org/D95764

This allows to check for various globals (metadata/attributes/...) and
also resolves problems with globals (metadata/attributes/...) being
reused across different prefixes.

Reviewed By: sstefan1

Differential Revision: https://reviews.llvm.org/D94741

Fixes PR49545

Reviewed By: zequanwu, fhahn, lebedev.ri

Differential Revision: https://reviews.llvm.org/D98444

D96109 added support for unique internal linkage names for both internal
linkage functions and global variables. There was a lot of discussion on how to
get the demangling right for functions but I completely missed the point that
demanglers do not support suffixes for global vars. For example:

$ c++filt _ZL3foo
foo
$ c++filt _ZL3foo.uniq.123
_ZL3foo.uniq.123

The demangling for functions works as expected.

I am not sure of the impact of this. I don't understand how debuggers and other
tools depend on the correctness of global variable demangling so I am
pre-emptively disabling it until we can get the demangling support added.

Importantly, uniquefying global variables is not needed right now as we do not
do profile attribution to global vars based on sampling. It was added for
completeness and so this feature is not exactly missed.

Differential Revision: https://reviews.llvm.org/D98392

Summary: This is a minor patch to add names for the debug line prologue, as a follow-up of D95998.

Reviewed By: dblaikie, ikudrin, shchenz

Differential Revision: https://reviews.llvm.org/D98383

This eliminates cross-header dependency from stdlib to string.

We don't support any other shuffles currently.

This changes the bswap/bitreverse tests that check for this in
their expansion code. Previously we expanded a byte swapping
shuffle through memory. Now we're scalarizing and doing bit
operations on scalars to swap bytes.

In the future we can probably use vrgather.vx to do a byte swap
shuffle.

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D97359

Reviewed By: EricWF, #libc, Quuxplusone, zoecarver

Differential Revision: https://reviews.llvm.org/D97443

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D97162

Reviewed By: EricWF, #libc, Quuxplusone

Differential Revision: https://reviews.llvm.org/D97359

Currently, BPF backend does not support all variants of
  atomic_load_{add,and,or,xor}, atomic_swap and atomic_cmp_swap
For example, it only supports 32bit (with alu32 mode) and 64bit
operations for atomic_load_{and,or,xor}, atomic_swap and
atomic_cmp_swap. Due to historical reason, atomic_load_add is
always supported with 32bit and 64bit.

If user used an unsupported atomic operation, currently,
codegen selectiondag cannot find bpf support and will issue
a fatal error. This is not user friendly as user may mistakenly
think this is a compiler bug.

This patch added Custom rule for unsupported atomic operations
and will emit better error message during ReplaceNodeResults()
callback. The following is an example output.

  $ cat t.c
  short sync(short *p) {
    return  __sync_val_compare_and_swap (p, 2, 3);
  }
  $ clang -target bpf -O2 -g -c t.c
  t.c:2:11: error: Unsupported atomic operations, please use 64 bit version
    return  __sync_val_compare_and_swap (p, 2, 3);
            ^
  fatal error: error in backend: Cannot select: t19: i64,ch =
    AtomicCmpSwap<(load store seq_cst seq_cst 2 on %ir.p)> t0, t2,
    Constant:i64<2>, Constant:i64<3>, t.c:2:11
    t2: i64,ch = CopyFromReg t0, Register:i64 %0
      t1: i64 = Register %0
    t11: i64 = Constant<2>
    t10: i64 = Constant<3>
  In function: sync
  PLEASE submit a bug report ...

Fatal error will still happen since we did not really do proper
lowering for these unsupported atomic operations. But we do get
a much better error message.

Differential Revision: https://reviews.llvm.org/D98471

This reverts commit f65e1aee.

The inlining of this function needs to be disabled as it is part of the
inpsected stack traces. It's string representation will look different
depending on if it was inlined or not which will cause it's string comparison
to fail.

When it was inlined in only one of the two execution stacks,
minimize_two_crashes.test failed on SystemZ. For details see
https://bugs.llvm.org/show_bug.cgi?id=49152.

Reviewers: Ulrich Weigand, Matt Morehouse, Arthur Eubanks

Differential Revision: https://reviews.llvm.org/D97975

As llvm.amdgcn.kill is lowered to a terminator it can cause
else branch annotations to end up in the wrong block.
Do not annotate conditionals as else branches where there is
a kill to avoid this.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D97427

Right now, when you have an invalid memory address, asan would just crash and does not offer much useful info.
This patch attempted to give a bit more detail on the access.

Differential Revision: https://reviews.llvm.org/D98280

This reverts commit 5eaeb0fa.

It appears there are analyses that assume clearing - example:
https://lab.llvm.org/buildbot#builders/36/builds/5964

Some linux distributions produce versioned llvm-symbolizer binaries,
e.g. my llvm-11 installation puts the symbolizer binary at
/usr/bin/llvm-symbolizer-11.0.0 . However if you then try to run
a binary containing ASAN with
ASAN_SYMBOLIZER_PATH=..../llvm-symbolizer-FOO , it will fail on startup
with "isn't a known symbolizer".

Although it is possible to work around this by setting up symlinks,
that's kindof ugly - supporting versioned binaries is a nicer solution.
(There are now multiple stack overflow and blog posts talking about
 this exact issue :) .)

Originally added in:
https://reviews.llvm.org/D8285

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D97682

This patch introduces progressive lowering patterns for rewriting
vector.transfer_read/write to vector.load/store and vector.broadcast
in certain supported cases.

Reviewed By: dcaballe, nicolasvasilache

Differential Revision: https://reviews.llvm.org/D97822

Check with the analysis result by calling invalidate instead of clear on
the analysis manager.

Differential Revision: https://reviews.llvm.org/D98440

Move (llvm-original-di-preservation) test example output into the Inputs directory (since it's an input to the test execution)

The "Inputs" subdirectory is used for all files read by the test, not
only those used as input to the execution - so even though this file is
used as a golden reference for the output of the test, it's still an
input to the test execution (it is read in the process of executing the
test).