Most of the removed includes should probably have been removed already
when we removed TargetMachine::adjustPassManager.

Getting rid of some include dependencies that seem to be outdated.

fixes https://github.com/llvm/llvm-project/issues/60241

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

The new combination exposed a crash in earlier versions of
D132063.

This commit adds a missing license header that was forgotten in
https://reviews.llvm.org/D143064.

alloc uses either `malloc` or a plugable allocation function for allocating the required memory. Both of these functions always return a `llvm.ptr<i8>`, aka a pointer in the default address space. When allocating for a memref in a different memory space however, no address space cast is created, leading to invalid LLVM IR being generated.

This is currently not caught by the verifier since the pointer to the memory is always bitcast which currently lacks a verifier disallowing address space casts. Translating to actual LLVM IR would cause the verifier to go off, since bitcast cannot translate from one address space to another: https://godbolt.org/z/3a1z97rc9

This patch fixes that issue by generating an address space cast if the address space of the allocation function does not match the address space of the resulting memref.

Not sure whether this is actually a real life problem. I found this issue while converting the pass to using opaque pointers which gets rid of all the bitcasts and hence caused type errors without the address space cast.

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

Cuda and rocm toolchain detectors are currently run unconditionally,
while their result may not be used at all. Make their initialization
lazy so that the discovery code is not run in common cases.

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

This just runs the existing tests through opt -O1, which helps canonicalizing
the code and adds additional flags which can be useful for matching.

This will allow IntrinsicCall to be used in passes to implement hlfir
transformational intrinsic operations.

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

This removes another dependency of IntrinsicCall upon flang/lib/Lower:
making it possible to move IntrinsicCall into flang/lib/Optimizer.

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

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

This will allow IntrinsicCall to be moved into lib/Optimizer later.

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

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

This removes IntrinsicCall's dependency upon StatementContext, which
will make it easier to move IntrinsicCall into flang/lib/Optimizer, for
use in passes.

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

SimplifyMultipleUseDemandedBits shouldn't be creating general nodes on the fly, it should mainly just peek through them (although we do currently allow creation of new bitcasts and constant folding).

This is mostly a win - by avoiding new nodes we avoid a lot of hasOneUse limitations inside x86 shuffle combining - the main regressions I've noticed are where we've ended up with multiple insert_subvector(undef, x, 0) nodes, widening x to different vector widths - that should hopefully be improved when we remove the last of the vector widening from combineX86ShufflesRecursively for Issue #45319

This adds "-pthreads" which appears to be a clang only
alias for "-pthread" (all the drivers check for both).

Use "-pthread" instead to be compatible with gcc.

Otherwise you get:
FAILED: bin/libc-gwp-asan-uaf-should-crash
: && /usr/bin/g++-11 <...> -pthreads <...> projects/libc/test/integration/scudo/liblibc_for_scudo_integration_test.a && :
g++-11: error: unrecognized command-line option ‘-pthreads’; did you mean ‘-pthread’?

Reviewed By: michaelrj

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

This is encoded in the `BufferizableOpInterface` via `resultBufferizesToMemoryWrite = false`.

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

After switching all LLVM IR import tests to opaque pointers
the specialized opaque pointer test file is redundant.

Reviewed By: Dinistro

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

Close https://github.com/llvm/llvm-project/issues/60544.

The root cause for the issue is that when we compile a module unit, the
file manager (and proprocessor and source manager) are owned by AST
instead of the compilaton instance. So the file manager may be invalid
when we want to create a time-report file for -ftime-trace when we are
compiling a module unit.

This patch tries to recreate the file manager for -ftime-trace if we
find the file manager is not valid.

As we prepare the tree to add more vendor-defined extensions that are
originating with T-Head, the debug message announcing the XTheadVdot
decoder namespace should refer to XTHeadVdot instead of all T-Head
custom extensions.

The revision addresses a bug during constant expression traversal
when importing LLVM IR. A constant expression may have cyclic
dependencies, for example, when a constant is initialized with its
address. This revision extends the constant expression traversal
to detect cyclic dependencies and adds a test to verify this
case is handled properly.

Reviewed By: Dinistro

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

The NextGen plugins use the information regarding new mapping/unmappings to
lock/unlock the corresponding host buffer and speed up the host-device memory
transfers involving those buffers. The locking/unlocking is disabled by default
and can be enabled by the LIBOMPTARGET_LOCK_MAPPED_HOST_BUFFERS envar. The
envar accepts boolean values (on/off) and a special option:
  - off:       Do not lock mapped host buffers (default).
  - on:        Lock mapped host buffers automatically, but do not report lock
               failures if the plugin fails to lock them.
  - mandatory: Lock mapped host buffers automatically and treat locking failures
               in the plugins as fatal errors. This option may be useful for
               debugging purposes.

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

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

`test-release.sh` is too silent in some cases:

- Only the build proper is run verbosely, but `check-all` is not.
- `lit` is run without `-v`, so in case of failures one cannot see what's
actually wrong.

This patch fixes both issues, running all `${MAKE}` invocations with
`$Verbose` (except for `${MAKE} install` where it would only add noise),
and running `lit` with `-v`.

Tested on `x86_64-pc-linux-gnu` and `arm64-apple-darwin21.6`.

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

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

This gets rid of a special case with CHAR() intrinsic and BIND(C) results.
I tested this has no impact on the LLVM assembly when LLVM opt -01 or
more is run.
See comment in the patch for more details.

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

The tablegen generated code is templated based on the type of Insn
passed to decodeInstruction which is currently uint32_t. All of the
fields extracted will this type.

Create X0 register directly instead of passing 0 to DecodeGPRRegisterClass.

This is used to help get simplified CFG for divergent regions as well as
get better code generation in some cases.

For example, with below IR:
```
define amdgpu_kernel void @test() {
bb:
  br label %bb1

bb1:
  %tmp = phi i32 [ 0, %bb ], [ %tmp5, %bb4 ]
  %tid = call i32 @llvm.amdgcn.workitem.id.x()
  %cnd = icmp eq i32 %tid, 0
  br i1 %cnd, label %bb4, label %bb2

bb2:
  %tmp3 = add nsw i32 %tmp, 1
  br label %bb4

bb4:
  %tmp5 = phi i32 [ %tmp3, %bb2 ], [ %tmp, %bb1 ]
  store volatile i32 %tmp5, ptr addrspace(1) undef
  br label %bb1
}
```

We got below assembly before the change:
```
  v_mov_b32_e32 v1, 0
  v_cmp_eq_u32_e32 vcc, 0, v0
  s_branch .LBB0_2
.LBB0_1:                                ; %bb4
                                        ;   in Loop: Header=BB0_2 Depth=1
  s_mov_b32 s2, -1
  s_mov_b32 s3, 0xf000
  buffer_store_dword v1, off, s[0:3], 0
  s_waitcnt vmcnt(0)
.LBB0_2:                                ; %bb
                                        ; =>This Inner Loop Header: Depth=1
  s_and_saveexec_b64 s[0:1], vcc
  s_xor_b64 s[0:1], exec, s[0:1]
                                        ; kill: def $sgpr0_sgpr1 killed $sgpr0_sgpr1 killed $exec
  s_cbranch_execnz .LBB0_1
; %bb.3:                                ; %bb2
                                        ;   in Loop: Header=BB0_2 Depth=1
  s_or_b64 exec, exec, s[0:1]
  s_waitcnt expcnt(0)
  v_add_i32_e64 v1, s[0:1], 1, v1
  s_branch .LBB0_1
```

After the change:
```
  s_mov_b32 s0, 0
  v_cmp_eq_u32_e32 vcc, 0, v0
  s_mov_b32 s2, -1
  s_mov_b32 s3, 0xf000
  v_mov_b32_e32 v0, s0
  s_branch .LBB0_2
.LBB0_1:                                ; %bb4
                                        ;   in Loop: Header=BB0_2 Depth=1
  buffer_store_dword v0, off, s[0:3], 0
  s_waitcnt vmcnt(0)
.LBB0_2:                                ; %bb1
                                        ; =>This Inner Loop Header: Depth=1
  s_and_saveexec_b64 s[0:1], vcc
  s_cbranch_execnz .LBB0_1
; %bb.3:                                ; %bb2
                                        ;   in Loop: Header=BB0_2 Depth=1
  s_or_b64 exec, exec, s[0:1]
  s_waitcnt expcnt(0)
  v_add_i32_e64 v0, s[0:1], 1, v0
  s_branch .LBB0_1
```

We are using one less VGPR, one less s_xor_, and better LICM with one
additional branch after the change. Please note the experiment
was done with reverting the workaround D139780, as it will stop the
tail-duplication completely for this case.

Reviewed by: arsenm

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

This reverts commit b27e4f72.

bccf5999 necessitates this revert.

Very likely breaks stage 3 of msan build bot.
Good: 764c88a5 https://lab.llvm.org/buildbot/#/builders/74/builds/17058
Looks unrelated: 48b5a06d
Bad: 48b5a06d https://lab.llvm.org/buildbot/#/builders/74/builds/17059

This reverts commit eb66833d.

Add RMPQUERY to the list of SNP instructions.
Tech Documentation: https://www.amd.com/system/files/TechDocs/24594.pdf

Reviewed By: RKSimon, craig.topper

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