See
https://lab.llvm.org/buildbot/#/builders/245/builds/21611/steps/5/logs/FAIL__Clang__constant-builtins-2_c.

GCC complains if we pass -Werror=format-security without -Wformat.
Reported at https://github.com/llvm/llvm-project/pull/83779#issuecomment-1985246797

As noted in
https://github.com/llvm/llvm-project/pull/84035#discussion_r1516817755
only files under the CPP folder should be in the `cpp` namespace.

Fixes #63216

* Add a conversion from `arith.constant` to `emitc.constant`.
* Drop the translation for `arith.constant`s.

This patch adds repository checks to the release-binaries workflow jobs.
People were observing that the job was running on a schedule in their
forks. This only happens on old forks, but those probably exist in great
number given how prolific LLVM is. This is also good practice anyways,
on top of solving the direct problem of these jobs running with the cron
schedule on people's forks.

These functions should not be allowed if the file position is
indeterminate (they return the file position).
This condition is now checked, and tests are improved to check it.

This adds operations for the unary minus and the unary plus operator.

This PR introduces a step after instruction selection where instructions
can be traversed from the perspective of their validity from the
specification point of view. The PR adds also a way to correct
load/store when there is a type mismatch contradicting the specification
-- an additional bitcast is inserted to keep types consistent.
Correspondent test cases are added and existing test cases are
corrected.

This PR helps to successfully validate with the `spirv-val` tool
(https://github.com/KhronosGroup/SPIRV-Tools) some output that
previously led to validation errors and crashes of back translation from
SPIRV to LLVM IR from the side of SPIRV Translator project
(https://github.com/KhronosGroup/SPIRV-LLVM-Translator).

The added step of bringing instructions to required by the specification
type correspondence can be (should be and will be) extended beyond
load/store instructions to ensure validity rules of other SPIRV
instructions related to type inference.

This patch implements
[CWG2586](https://cplusplus.github.io/CWG/issues/2583.html) "Common
initial sequence should consider over-alignment". Note that alignment of
union members doesn't have to match, as layout compatibility of unions
is not defined in terms of common initial sequence
(http://eel.is/c++draft/class.mem.general#25).

Attempt 2. The first one was trying to call isa<> on an MI reference that was free'd.

This reverts commit ee24409c.

Fixes that
```
Pattern {
  let tuple = (attr<"3 : i34">);
  not tuple.0;
  erase _;
}
```
would crash the PDLL parser because it expected a native constraint
after `not`.

These checks have been broken since 6afe9721.
The check_cxx_compiler_flag macro only takes two arguments and passing
three to it ends up calling
`cmake_check_compiler_flag(CXX "${_FLAG}" ${_RESULT})` with ${_FLAG}
equal to `-Werror` and the result variable being the actually tested
compiler flag.

I noticed this because some of the flags that I know should be supported
were being flagged as not supported. `--debug-trycompile` shows the
following surprising line in the generated CMakeLists.txt:
`add_definitions([==[-D-Wempty-body]==] [==[-Werror]==])` which then
results in the following error while running the check:
```
FAILED: CMakeFiles/cmTC_72736.dir/src.cxx.o
tmp/upstream-llvm-readonly/bin/clang++   -nodefaultlibs -std=c++17 -fcolor-diagnostics   -D-Wempty-body -Werror -MD -MT CMakeFiles/cmTC_72736.dir/src.cxx.o -MF CMakeFiles/cmTC_72736.dir/src.cxx.o.d -o CMakeFiles/cmTC_72736.dir/src.cxx.o -c .../cmake-build-all-sanitizers/CMakeFiles/CMakeScratch/TryCompile-nyh3QR/src.cxx
In file included from <built-in>:450:
<command line>:1:9: error: macro name must be an identifier
    1 | #define -Wempty-body 1
      |         ^
   1 error generated.
```

It would be great if CMake could be a bit more helpful here so I've
filed https://gitlab.kitware.com/cmake/cmake/-/issues/25735.

See also https://reviews.llvm.org/D146920.

Reviewed By: nikic

Pull Request: https://github.com/llvm/llvm-project/pull/83779

I'm making some changes to `Environment::getResultObjectLocation()`,
with the
ultimate goal of eliminating `RecordValue` entirely, and I'd like to
make sure
I don't break this behavior (and I've realized we don't have a test for
it yet).

This is the constructor's job, and we want to be able to test that it
does this.

With the many pseudos used in SVE codegen it can be too easy to miss
instructions. This enables the existing test we have for checking the
scheduling info of the pseudos matches the real instructions, and
adjusts the scheduling info in the NeoverseV1 model to make sure all are
handled. In the cases I could I opted to use the same info as in the
NeoverseV2 model, to keep the differences smaller.

Older versions of clang do not have __builtin_complex, but they
may define `__GNUC__`.

Resubmitting this after previous revert with the following changes:

- Split table into table_rhs_idx and table_candidate_idx so that
  bisect.bisect_left can be used without the `key` argument, which
  was introduced in Python 3.10
- Remove a re.Pattern type annotation

Original commit message:

Prior to this change, running UTC on larger tests, especially tests
with unnamed IR values, often resulted in a spuriously large diff
because e.g. TMPnn variables in the CHECK lines were renumbered. This
change attempts to reduce the diff by keeping those variable names the
same.

There are cases in which this "drift" of variable names can end up being
more confusing. The old behavior can be re-enabled with the
--reset-variable-names command line argument.

The improvement may not be immediately apparent in the diff of this change.
The point is that the diff of stable_ir_values.ll against
stable_ir_values.ll.expected after this change is smaller.

Ideally, we'd also keep meta variables for "global" objects stable, e.g.
for attributes (#nn) and metadata (!nn). However, that would require a
much more substantial refactoring of how we generate check lines, so I
left it for future work.

This reverts commit fb02f9ac.

Looks like some Python version incompatibility, will investigate.

PR #75982 had been created before these tests were added, therefore
some test were not updated.

Prior to this change, running UTC on larger tests, especially tests
with unnamed IR values, often resulted in a spuriously large diff
because e.g. TMPnn variables in the CHECK lines were renumbered. This
change attempts to reduce the diff by keeping those variable names the
same.

There are cases in which this "drift" of variable names can end up being
more confusing. The old behavior can be re-enabled with the
--reset-variable-names command line argument.

The improvement may not be immediately apparent in the diff of this change.
The point is that the diff of stable_ir_values.ll against
stable_ir_values.ll.expected after this change is smaller.

Ideally, we'd also keep meta variables for "global" objects stable, e.g.
for attributes (#nn) and metadata (!nn). However, that would require a
much more substantial refactoring of how we generate check lines, so I
left it for future work.

The match argument isn't used.

The match argument is unused.

The test case demonstrates how meta variables are needlessly renamed,
making diffs harder to read.

llvm-project/clang/lib/Frontend/FrontendActions.cpp:213:10:
error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move]
  213 |   return std::move(Consumers);
      |          ^
/Users/jiefu/llvm-project/clang/lib/Frontend/FrontendActions.cpp:213:10: note: remove std::move call here
  213 |   return std::move(Consumers);
      |          ^~~~~~~~~~         ~
1 error generated.

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

See

https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755

This patch introduces reduced BMI, which doesn't contain the definitions
of functions and variables if its definitions won't contribute to the
ABI.

Testing is a big part of the patch. We want to make sure the reduced BMI
contains the same behavior with the existing and relatively stable
fatBMI. This is pretty helpful for further reduction.

The user interfaces part it left to following patches to ease the
reviewing.

llvm-project/mlir/lib/Dialect/Linalg/Transforms/MeshShardingInterfaceImpl.cpp:96:8:
error: unused variable 'resultElementType' [-Werror,-Wunused-variable]
  Type resultElementType =
       ^
llvm-project/mlir/lib/Dialect/Linalg/Transforms/MeshShardingInterfaceImpl.cpp:122:1:
error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
2 errors generated.

This commit adds listener support to the dialect conversion. Similarly
to the greedy pattern rewrite driver, an optional listener can be
specified in the configuration object.

Listeners are notified only if the dialect conversion succeeds. In case
of a failure, where some IR changes are first performed and then rolled
back, no notifications are sent.

Due to the fact that some kinds of rewrite are reflected in the IR
immediately and some in a delayed fashion, there are certain limitations
when attaching a listener; these are documented in `ConversionConfig`.
To summarize, users are always notified about all rewrites that
happened, but the notifications are sent all at once at the very end,
and not interleaved with the actual IR changes.

This change is in preparation improvements to
`transform.apply_conversion_patterns`, which currently invalidates all
handles. In the future, it can use a listener to update handles
accordingly, similar to `transform.apply_patterns`.

During block signature conversion, a new block is inserted and ops are
moved from the old block to the new block. This commit changes the
implementation such that ops are moved in bulk (`splice`) instead of
one-by-one; that's what `splitBlock` is doing.

This also makes it possible to pass the new block argument types
directly to `createBlock` instead of using `addArgument` (which bypasses
the rewriter). This doesn't change anything from a technical point of
view (there is no rewriter API for adding arguments at the moment), but
the implementation reads a bit nicer.

Allows linalg structured operations to be handled during spmdization and
sharding propagation.

There is only support for projected permutation indexing maps.

Link: https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322

Link: https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322

When dumping FDEs, `readelf` prints new location values after
`DW_CFA_advance_loc(*)` instructions, which looks quite convenient:

```
> readelf -wf test.o
...
... FDE ... pc=0000000000000030..0000000000000064
  DW_CFA_advance_loc: 4 to 0000000000000034
  ...
  DW_CFA_advance_loc: 4 to 0000000000000038
...
```

This patch makes `llvm-dwarfdump` and `llvm-readobj` do the same.

The saved state of the AARCH64_DWARF_PAUTH_RA_STATE register was not
updated, so `llvm-dwarfdump` continued to dump it as `reg34=1` even if
the correct value is `0`:

```
> llvm-dwarfdump -v test.o
...
0000002c 00000024 00000030 FDE cie=00000000 pc=00000030...00000064
  Format:       DWARF32
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_advance_loc: 4
  DW_CFA_def_cfa_offset: +16
  DW_CFA_offset: W30 -16
  DW_CFA_remember_state:
  DW_CFA_advance_loc: 16
  DW_CFA_def_cfa_offset: +0
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_restore: W30
  DW_CFA_advance_loc: 4
  DW_CFA_restore_state:
  DW_CFA_advance_loc: 12
  DW_CFA_def_cfa_offset: +0
  DW_CFA_advance_loc: 4
  DW_CFA_AARCH64_negate_ra_state:
  DW_CFA_restore: W30
  DW_CFA_nop:

  0x30: CFA=WSP
  0x34: CFA=WSP: reg34=1
  0x38: CFA=WSP+16: W30=[CFA-16], reg34=1
  0x48: CFA=WSP: W30=[CFA-16], reg34=1
  0x4c: CFA=WSP: reg34=1               <--- should be '=0'
  0x50: CFA=WSP+16: W30=[CFA-16], reg34=1
  0x5c: CFA=WSP: W30=[CFA-16], reg34=1
  0x60: CFA=WSP: reg34=1               <--- should be '=0'
```

This PR adds OMP runtime support for more efficient partitioning of
certain types of collapsed loops that can be used by compilers that
support loop collapsing (i.e. MSVC) to achieve more optimal thread load
balancing.

In particular, this PR addresses double nested upper and lower isosceles
triangular loops of the following types

1. lower triangular 'less_than'
   for (int i=0; i<N; i++)
     for (int j=0; j<i; j++)
2. lower triangular 'less_than_equal'
   for (int i=0; i<N; j++)
     for (int j=0; j<=i; j++)
3. upper triangular
   for (int i=0; i<N; i++)
     for (int j=i; j<N; j++)

Includes tests for the three supported loop types.

---------

Co-authored-by: Vadim Paretsky <b-vadipa@microsoft.com>