Need to check that the minimum acceptable vector factor is at least 2,
not 0, to avoid compiler crash during gathered loads analysis.

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

This introduces a builder function for emitting IR performing reductions in
OpenMP. Reduction variable privatization and initialization to the
reduction-neutral value is expected to be handled separately. The caller
provides the reduction functions. Further commits can provide implementation of
reduction functions for the reduction operators defined in the OpenMP
specification.

This implementation was tested on an MLIR fork targeting OpenMP from C and
produced correct executable code.

Reviewed By: Meinersbur

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

This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.

Review By: jankratochvil, dblaikie

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

The test contains a race in memset.
The size of reported race depends on how the accessed
memory range split into granules inside of tsan runtime.
The test used to report access of size 8, because presumably
the buffer ended up being aligned to 8 bytes. But after
some unrelated changes this test started to report accesses
of size 1 (presumably .data layout changed), which makes
the test fail.
Guarantee alignment of the buf object explicitly.

Reviewed By: melver

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

Make New<>() a variadic function template and forward any arguments to
the constructor. std::forward<>() is inlined to avoid including
<utility>.

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

The "memory tag read" command will now tell you
when the allocation tag read does not match the logical
tag.

(lldb) memory tag read mte_buf+(8*16) mte_buf+(8*16)+48
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7080, 0xfffff7ff7090): 0x8 (mismatch)
[0xfffff7ff7090, 0xfffff7ff70a0): 0x9
[0xfffff7ff70a0, 0xfffff7ff70b0): 0xa (mismatch)

The logical tag will be taken from the start address
so the end could have a different tag. You could for example
read from ptr_to_array_1 to ptr_to_array_2. Where the latter
is tagged differently to prevent buffer overflow.

The existing command will read 1 granule if you leave
off the end address. So you can also use it as a quick way
to check a single location.

(lldb) memory tag read mte_buf
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7000, 0xfffff7ff7010): 0x0 (mismatch)

This avoids the need for a seperate "memory tag check" command.

Reviewed By: omjavaid

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

The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1

This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.

We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.

Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.

Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.

Reviewed By: omjavaid

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

The presence of AffineIfOp inside AffineFor prevents fusion of the other loops to happen. For example:

```
  affine.for %i0 = 0 to 10 {
    affine.store %cf7, %a[%i0] : memref<10xf32>
  }
  affine.for %i1 = 0 to 10 {
    %v0 = affine.load %a[%i1] : memref<10xf32>
    affine.store %v0, %b[%i1] : memref<10xf32>
  }
  affine.for %i2 = 0 to 10 {
    affine.if #set(%i2) {
      %v0 = affine.load %b[%i2] : memref<10xf32>
    }
  }
```

The first two loops were not be fused because of `affine.if` inside the last `affine.for`.

The issue seems to come from a conservative constraint that does not allow fusion if there are ops whose number of regions != 0 (affine.if is one of them).

This patch just removes such a constraint when`affine.if` is inside `affine.for`.  The existing `canFuseLoops` method is able to handle `affine.if` correctly.

Reviewed By: bondhugula, vinayaka-polymage

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

We frequenty allocate sizeof(T) memory and call T ctor on that memory
(C++ new keyword effectively). Currently it's quite verbose and
usually takes 2 lines of code.
Add New<T>() helper that does it much more concisely.

Rename internal_free to Free that also sets the pointer to nullptr.
Shorter and safer.

Rename internal_alloc to Alloc, just shorter.

Reviewed By: vitalybuka, melver

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

spirv::getElementPtr can return null (for memrefs with affine map) but patterns didn't handle this.

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

There is a SIGSEGV at `DeduceTemplateArgumentsByTypeMatch`. The bug [#51171](https://bugs.llvm.org/show_bug.cgi?id=51171) was filled. The reproducer can be found at the bug description.

LIT test for the issue was added:
```
./bin/llvm-lit -v ../clang/test/SemaCXX/pr51171-crash.cpp
```

The debug stack trace is below:
```
 #0 0x00000000055afcb9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:22
 #1 0x00000000055afd70 PrintStackTraceSignalHandler(void*) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1
 #2 0x00000000055add2d llvm::sys::RunSignalHandlers() /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Signals.cpp:97:20
 #3 0x00000000055af701 SignalHandler(int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1
 #4 0x00007ffff7bc2b20 __restore_rt sigaction.c:0:0
 #5 0x00007ffff66a337f raise (/lib64/libc.so.6+0x373...

The updated lots_of_threads.c test with 300 threads
started running for too long on machines with low
hardware parallelism (e.g. taskset -c 0-1).
On lots of CPUs it finishes in ~2 secs. But with
taskset -c 0-1 it runs for hundreds of seconds
effectively spinning in the barrier in the sleep loop.

We now have the handy futex API in sanitizer_common.
Use it instead of the passive spin loop.
It makes the test run only faster with taskset -c 0-1,
it runs for ~1.5 secs, while with full parallelism
it still runs for ~2 secs (but consumes less CPU time).

Depends on D107131.

Reviewed By: vitalybuka

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

The test contains a race in read/write syscalls.
The size of reported race depends on how the accessed
memory range split into granules inside of tsan runtime.
The test used to report access of size 8, because presumably
the buffer ended up being aligned to 8 bytes. But after
some unrelated changes this test started to report accesses
of size 1 (presumably .data layout changed), which makes
the test fail.
Guarantee alignment of the buf object explicitly.

Reviewed By: vitalybuka, melver

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

Under MVE we can use VADDV/VADDVA's to perform integer add reductions,
so it can be beneficial to use more reductions than summing subvectors
and reducing once. Especially for VMLAV/VMLAVA the mul can be
incorporated into the reduction, producing less instructions.

Some of the test cases currently get larger due to extra integer adds,
but will be improved in a followup patch.

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

These are generated from SLP vectorization, for example
https://godbolt.org/z/ebxdPh1Kz. These backend tests
show cases that we can produce better code for.

This reverts commit fed25ddc.

There has been sporadic failures in LLDB AArch64/Arm 32 buildbots since
this commit. I am temporarily reverting it see if it fixes the issue.

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

Renamed language standard from openclcpp to openclcpp10.
Added new std values i.e. '-cl-std=clc++1.0' and
'-cl-std=CLC++1.0'.

Patch by Topotuna (Justas Janickas)!

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

Remove erroneous `||` at the end of an `if` condition. This was
introduced in https://reviews.llvm.org/D106871.

The Scalable Matrix Extension (SME) introduces a new execution mode
called Streaming SVE mode. In streaming mode a substantial subset of the
SVE and SVE2 instruction set is available, along with new outer product,
load, store, extract and insert instructions that operate on the new
architectural register state for the matrix.

To support streaming mode this patch introduces a new subtarget feature
+streaming-sve. If enabled, the subset of SVE(2) instructions are
available. The existing behaviour for SVE(2) remains unchanged, the
subset of instructions that are legal in streaming mode are enabled if
either +sve[2] or +streaming-sve is specified. Instructions that are
illegal in streaming mode remain predicated on +sve[2].

The SME target feature has been updated to imply +streaming-sve rather
than +sve.

The following changes are made to the SVE(2) tests:
  * For instructions that are legal in streaming mode:
    - added RUN line to verify +streaming-sve enables the instruction.
    - updated diagnostic to 'instruction requires: streaming-sve or sve'.
  * For instructions that are illegal in streaming-mode:
    - added RUN line to verify +streaming-sve does not enable the
      instruction.

SVE(2) instructions that are legal in streaming mode have:

  if !HaveSVE[2]() && !HaveSME() then UNDEFINED;

at the top of the pseudocode in the XML.

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2021-06/SVE-Instructions

Reviewed By: sdesmalen, david-arm

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

This saves a level of manual table lookup for those of us who don't remember
ELF relocation numbers off the top of our heads.

Pulled out the OptimizationLevel class from PassBuilder in order to be able to access it from within the PassManager and avoid include conflicts.

Reviewed By: mtrofin

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

CL 2.0 introduced atomics and generic address space so there were
only one set of APIs for doing atomics, however since CL 3.0
makes generic address space optional, there has to be new sets
of atomic interfaces to handle that cases.

Reviewed By: Anastasia

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

to fail due to warnings as errors. Note that I could not reproduce the
problem locally, but based on the messages, I think this change will fix
the errors.

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

This reverts commit d1e4b257.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to construct actual pipe. This feature
requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well.

Reviewed By: Anastasia

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

Regsier hints when copying to a UACC register do not always produce VSRp
registers. This patch makes sure that we do not produce hints in cases
where the subregsiter of the UACC is not a VSRp.

Reviewed By: nemanjai, #powerpc

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

Summary: Add support for yaml2obj to parse 64-bit XCOFF.

Reviewed By: shchenz

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

It was suggested in https://reviews.llvm.org/D105741 and it makes sense.

This feature requires support of __opencl_c_images, so diagnostics for that is provided as well.
Also, ensure that cl_khr_3d_image_writes feature macro is set to the same value.

Reviewed By: Anastasia

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

- clang-ppc64le-rhel bot LIT failure: https://lab.llvm.org/buildbot/#/builders/57/builds/8932
- culprit change: https://reviews.llvm.org/D107050

nm does not show size for aliased symbols,
we should still extract them if they are external.

Reviewed By: hubert.reinterpretcast

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

https://reviews.llvm.org/D45592 added a nice feature to be able to specify a breakpoint by a relative path. E.g. passing foo.cpp or bar/foo.cpp or zaz/bar/foo.cpp is fine. However, https://reviews.llvm.org/D68671 by mistake disabled the test that ensured this functionality works. With time, someone made a small mistake and fully broke the functionality.

So, I'm making a very simple fix and the test passes.

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

This patch makes it possible to list a td_library as a rule's data
attribute and get its source files and all its transitive dependencies
at runtime. This is useful for, e.g. shell tests running tblgen.

Note that this is a bit different from how a "normal" (e.g. C++) library
rule would work because those have actual library outputs and the
td_library rule just bundles some source files and includes. If someone
wanted to make use of the includes, they would have to access the TdInfo
provider, but this keeps simple things simple.

Reviewed By: jpienaar

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

These are unconditionally included in the CMake build as well and
necessary for some odd platforms (even though the C++11 standard says
they shouldn't be).

Reviewed By: chandlerc

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

This makes the logic used to determine if targets have the given
features the same as is used in CMake. Incidentally, it enables these
features for the targets added in https://reviews.llvm.org/D106921
which were missing because this was previously a hardcoded list.

Reviewed By: chandlerc

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

Add disassembler support for the NORM and NORMH instructions. These instructions
only exist when the ARC processor is configured with the "norm" extension.

fferential Revision: https://reviews.llvm.org/D107118

* Broken out of https://reviews.llvm.org/D106419
* Otherwise, same named modules will conflict with each other.

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

This patch does the following optimization of mul with a constant.

(mul x, 11) -> (SH1ADD (SH2ADD x, x), x)
(mul x, 19) -> (SH1ADD (SH3ADD x, x), x)
(mul x, 13) -> (SH2ADD (SH1ADD x, x), x)
(mul x, 21) -> (SH2ADD (SH2ADD x, x), x)
(mul x, 37) -> (SH2ADD (SH3ADD x, x), x)
(mul x, 25) -> (SH3ADD (SH1ADD x, x), x)
(mul x, 41) -> (SH3ADD (SH2ADD x, x), x)
(mul x, 73) -> (SH3ADD (SH3ADD x, x), x)
(mul x, 27) -> (SH1ADD (SH3ADD x, x), (SH3ADD x, x))
(mul x, 45) -> (SH2ADD (SH3ADD x, x), (SH3ADD x, x))
(mul x, 81) -> (SH3ADD (SH3ADD x, x), (SH3ADD x, x))

Reviewed By: craig.topper

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

Reviewed By: craig.topper

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

Reviewed By: Ben Shi

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