Previously, bitwise shifts with constant operands were validated by the
checker `core.UndefinedBinaryOperatorResult`. However, this logic was
unreliable, and commit 25b9696b added
the dedicated checker `core.BitwiseShift` which validated the
preconditions of all bitwise shifts with a more accurate logic (that
uses the real types from the AST instead of the unreliable type
information encoded in `APSInt` objects).

This commit disables the inaccurate logic that could mark bitwise shifts
as 'undefined' and removes the redundant shift-related warning messages
from core.UndefinedBinaryOperatorResult. The tests that were validating
this logic are also deleted by this commit; but I verified that those
testcases trigger the expected bug reports from `core.BitwiseShift`. (I
didn't convert them to tests of `core.BitwiseShift`, because that
checker already has its own extensive test suite with many analogous
testcases.)

I hope that there will be a time when the constant folding will be
reliable, but until then we need hacky solutions like this improve the
quality of results.

Summary:
Previously this code was applied to the integration tests but did not
copy the logic that stopped this from being passed to the GPU build.
Copy the full line to avoid the warnings and prevent any libraries from
being included.

-- SoftmaxOp's `reifyResultShapes` function was wrongly casting it as a
`LinalgOp`.
-- This commit thus adds a fix to SoftmaxOp's reify result shape
calculation.

Signed-off-by: Abhishek Varma <abhishek@nod-labs.com>

On ELF platforms, when there is no global variable, COMDAT asan.module_ctor is
created with no `__asan_register_elf_globals` calls. If this COMDAT is the
prevailing copy selected by the linker, the linkage unit will have no
`__asan_register_elf_globals` call: the redzone will not be poisoned and ODR
violation checker will not work (#67677).

This behavior is benign for -fno-sanitize-address-globals-dead-stripping because
asan.module_ctor functions that call `__asan_register_globals`
(`InstrumentGlobalsWithMetadataArray`) do not use COMDAT.

To fix #67677:

* Use COMDAT for -fsanitize-address-globals-dead-stripping on ELF platforms.
* Call `__asan_register_elf_globals` even if there is no global variable.

Alternatively, when there is no global variable, asan.module_ctor is not COMDAT
and does not call `__asan_register_elf_globals`. However, the asan.module_ctor
function cannot be eliminated by the linker.

Tested the following script. Only ELF -fsanitize-address-globals-dead-stripping has changed behaviors.
```
echo > a.cc  # no global variable, empty uniqueModuleId
echo 'void f() {}' > b.cc  # with global variable, with uniqueModuleId
echo 'int g;' > c.cc  # with global variable
for t in x86_64-linux-gnu arm64-apple-macosx x86_64-windows-msvc; do
  for gc in -f{,no-}sanitize-address-globals-dead-stripping; do
    for f in a.cc b.cc c.cc; do
      echo /tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o -
      /tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o - | sed -n '/asan.module_ctor/,/ret/p'
    done
  done
done
```

Similar to 806761a7

LLDB_EXPORT_ALL_SYMBOLS is useful when building out-of-tree plugins and
extensions that rely on LLDB's internal symbols. For example, this is
how the Mojo language provides its REPL and debugger support.

Supporting this on windows is kind of tricky because this is normally
expected to be done using dllexport/dllimport, but lldb uses these with
the public api. This PR takes an approach similar to what LLVM does with
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS, and what chromium does for
[abseil](https://github.com/chromium/chromium/blob/253d14e20fdc0cab05e5516770dceca18f9bddaf/third_party/abseil-cpp/generate_def_files.py),
and uses a python script to extract the necessary symbols by looking at
the symbol table for the various lldb libraries.

These don't affect the IR, so we should ignore them.

Similar to commit 806761a7 to avoid issues due
to object file format differences. These tests are currently benign.

This patch makes sure that everything is cleaned up properly
when ExprConstant evaluates an ArrayInitLoopExpr.

Fixes #57135

This patch starts the support for OpenMP kernel language, basically to
write
OpenMP target region in SIMT style, similar to kernel languages such as
CUDA.
What included in this first patch is the `ompx_bare` clause for `target
teams`
directive. When `ompx_bare` exists, globalization is disabled such that
local
variables will not be globalized. The runtime init/deinit function calls
will
not be emitted. That being said, almost all OpenMP executable directives
are
not supported in the region, such as parallel, task. This patch doesn't
include
the Sema checks for that, so the use of them is UB. Simple directives,
such as
atomic, can be used. We provide a set of APIs (for C, they are prefix
with
`ompx_`; for C++, they are in `ompx` namespace) to get thread id, block
id, etc.
For more details, you can refer to
https://tianshilei.me/wp-content/uploads/llvm-hpc-2023.pdf.

They're still non-standard in C++17.

#67167 reports a potential memory overflow caused by the wrong size
passed to the function `memcpy_s`. This patch fixes it.

Fix #67167.

Added extra comment that should clarify the need for an insertion guard
when using `getLoopOverTileSlices`. Also removed some redundant calls to
`setInsertionPointAfter` - the insertion guard would overwrite that on
destruction anyway.

This is probably a copy-and-paste error and the variable 'more' was left
unused.

This fixes up the generation of 128bit atomic, volatile and non-temporal
loads/stores, under the assumption that they should usually be the same as
standard versions.
https://godbolt.org/z/xxc89eMKE

Fixes #64580
Closes #67413

Following on from D135150, this patch fixes another crash caused by this
DAG combine:

fadd (fma A, B, (fmul C, D)), E --> fma A, B, (fma C, D, E)

The combine calls ReplaceAllUsesOfValueWith to replace (fmul C, D) with
(fma C, D, E). This can cause nodes to get CSEd. In D135150 the problem
was that the (fma C, D, E) node got CSEd away. In this new case, the
problem is that the outer fadd node gets CSEd away. To fix it we have
to return SDValue(N, 0) from the combine and be careful not to add a
deleted node to the worklist.

[AArch64] Fix FMV ifunc resolver usage on old Android APIs. Rename internal compiler-rt FMV functions.

The patch fixes Function Multi Versioning features detection by ifunc
resolver on Android API levels < 30.
Ifunc hwcaps parameters are not supported on Android API levels 23-29,
so all CPU features are set unsupported if they were not initialized
before ifunc resolver call.
There is no support for ifunc on Android API levels < 23, so Function
Multi Versioning is disabled in this case.

Also use two underscore prefix for FMV runtime support functions to
avoid conflict with user program ones.

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

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

This is the `ASTReader` counterpart to PR #67383.

This patch adds a flag to LLVM such that the output generated by the
`-print-(before|after|all)`
family of flags is written to files in a directory rather than to
stderr.

This new flag is `-ir-dump-directory` and is used to specify where to
write the files. No other flags are added, it just modifies the behavior
of the print flags.

This is a second simplified version of the changes proposed in
https://github.com/llvm/llvm-project/pull/65179

.

This patch only adds support for the new pass manager. If this patch is
accepted, similar support can be added to the legacy pass manager.

Co-authored-by: Nuri Amari <nuriamari@fb.com>

Also default to disassembling a and m features
Some code taken from https://reviews.llvm.org/D62732 , which hasn't been
updated in a year.

Tested with 32 and 64 bit Linux user space QEMU

Reviewed By: jasonmolenda

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

It's subsumed by an order of magnitude more popular `vectorization` label that is applied for the same path patterns.

Statistics (issues and PRs together):
`vectorization`: 91 open, 91 closed
`vectorizers`: 8 open, 5 closed 

All `vectorizers` usages has occurred in just the past 2 weeks, and likely by our bot.

This patch adds the PNR_3b regclass for predicate-as-counter registers
0-7 and allows the Upl ASM constraint to use this register class.

And adjust an existing test to not be a simple reduction to preserve test intent.

Need to consider the length of the original vector for extractelements,
not the length, matched number of the scalars. It fixes 2 issues: 1)
improves cost estimation; 2) Fixes crashes after D158449.

At the moment, `hoistRedundantVectorTransfers` would hoist the
`vector.transfer_read`/`vector.transfer_write` pair in this function:

```mlir
func.func @no_hoisting_write_to_memref(%rhs: i32, %arg1: vector<1xi32>) {
  %c0_i32 = arith.constant 0 : i32
  %c0 = arith.constant 0 : index
  %c1 = arith.constant 1 : index
  %c4 = arith.constant 4 : index
  %c20 = arith.constant 20 : index
  %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32>
  %cast = memref.cast %alloca : memref<1x1x2xi32> to memref<1x1x2xi32>
  %collapsed_1 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
  scf.for %_ = %c0 to %c20 step %c4 {
    %collapsed_2 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %lhs = vector.transfer_read %collapsed_1[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %acc = vector.transfer_read %collapsed_2[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %op = vector.outerproduct %lhs, %rhs, %acc {kind = #vector.kind<add>} : vector<1xi32>, i32
    vector.transfer_write %op, %collapsed_1[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32>
  }
  return
}
```
as follows:
```mlir
  func.func @no_hoisting_write_to_memref(%arg0: i32, %arg1: vector<1xi32>) {
    %c0_i32 = arith.constant 0 : i32
    %c0 = arith.constant 0 : index
    %c4 = arith.constant 4 : index
    %c20 = arith.constant 20 : index
    %alloca = memref.alloca() {alignment = 64 : i64} : memref<1x1x2xi32>
    %collapse_shape = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %collapse_shape_0 = memref.collapse_shape %alloca [[0, 1, 2]] : memref<1x1x2xi32> into memref<2xi32>
    %0 = vector.transfer_read %collapse_shape[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %1 = vector.transfer_read %collapse_shape_0[%c0], %c0_i32 {in_bounds = [true]} : memref<2xi32>, vector<1xi32>
    %2 = scf.for %arg2 = %c0 to %c20 step %c4 iter_args(%arg3 = %0) -> (vector<1xi32>) {
      %3 = vector.outerproduct %arg3, %arg0, %1 {kind = #vector.kind<add>} : vector<1xi32>, i32
      scf.yield %3 : vector<1xi32>
    }
    vector.transfer_write %2, %collapse_shape[%c0] {in_bounds = [true]} : vector<1xi32>, memref<2xi32>
    return
  }
```

This is not safe. While one argument for `vector.outerproduct` (`%rhs`
from the original loop) is correctly being forwarded via `iter_args`,
the other one (`%acc` from the original loop) is not.

This patch disables hoisting in cases where the source of "candidate"
`vector.transfer_read` aliases with some other `memref`. A more generic
approach would be to make sure that all values are correctly forwarded
via `iter_args`, but that would require involving alias analysis.

[1] Based on https://github.com/openxla/iree/issues/14994.

The file format on z/OS is called GOFF (Generalized Object File Format),
not GCOFF.

…oadcast functions

Reapply "[libc++][ranges] Add benchmarks for the `from_range` constructors of `vector` and `deque`." (#67753)

This reverts commit 10edd5d9 and guards
against older versions of GCC to work around the problem.

Since we moved to Github PRs, the workflow has changed a bit and folks
often merge `main` back into their PR branch. This is fine, except the
previous way of determining modified files for pre-commit CI would use
the content modified just in the latest commit, whatever it is. This
means that in case someone merged main back into their PR branch, we'd
think that the files in the merge commit were modified by the PR, and
we'd spuriously trigger a CI run. This should fix this issue.

The downside is that the merge target is hardcoded to `main`, which
might not always be what we want. I still think this is an improvement
over the status quo.

The threading library does not recognize AIX and always returns `-1` for
number of physical cores on AIX. This PR teaches the library to
recognize AIX and obtain the correct value for the number of physical
cores.

I just found that we didn't handle the imports in GMF of PMF when we're
generating the init functions for the current module unit. This looks
like a simple oversight and I'm going to fix that in this patch
directly.