I finally snapped and fixed this inconsistency.

This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.

The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.

In summary, the linker translates input:

```
    .text
  entry:
  __acle_se_entry:
    [entry_code]

```
into:

```
    .section .gnu.sgstubs
  entry:
    SG
    B.W __acle_se_entry

    .text
  __acle_se_entry:
    [entry_code]
```

If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.

If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.

If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.

Reviewed By: MaskRay, peter.smith

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

Whether we include operator new and delete into libc++ has always
been a build time setting, and piggy-backing on a macro like
_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is inconsistent with how
we handle similar cases for e.g. LIBCXX_ENABLE_RANDOM_DEVICE. Instead,
simply avoid including new.cpp in the sources of the library when we
do not wish to include these operators in the build.

This also makes us much closer to being able to share the definitions
between libc++ and libc++abi, since we could technically build those
definitions into a standalone static library and decide whether we link
it into libc++abi.dylib or libc++.dylib.

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

The failing test comes from https://reviews.llvm.org/D152570.
Root cause of the failure is that a string constant on SystemZ
has an alignment of 2, not 1. The CSKY target has a similar problem.
The solution is to replace the fixed number with a regex.

Reviewed By: uweigand, tuliom, Zibi

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

Once integrated in our codebase the patch triggered a bunch of failing
tests. We do not yet understand where the bug is but we revert it to
move forward with integration.
This reverts commit 5e32765c.

This one is a bit twisted. Some platforms don't have support for
exiting in a clean manner, so they don't provide std::exit(). As
a result, defining `terminate_successful()` on those platforms won't
work, and the PSTL tests that rely on `terminate_successful()` also
won't work.

However, we don't have a notion of "no clean termination" in libc++,
so we can't properly guard this. Since embedded platforms that don't
support clean termination usually also don't enable exceptions, we
don't need to be able to run those `terminate_successful` PSTL tests,
and guarding the definition of `terminate_successful` with
TEST_HAS_NO_EXCEPTIONS works pretty well.

This is kind of a hack for the lack of having a concept of "no clean
termination" in the library and in the test suite.

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

This reverts commit e83c8c36.

Depending only on the support header files is not sufficient.

AMDGPUAtomicOptimizer updates the dominator tree whenever
it modified the control flow. Therefore preserving the
analysis similar to legacy PM.

Reviewed By: arsenm, yassingh, #amdgpu

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

Reviewed By: kkwli0

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

Possible misleading comment has been addressed.

Reviewed By: jasonmolenda

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

This teaches DumpRegisterInfo to generate a table from the register
flags type. It just calls a method on RegisterFlags.

As such, the extra tests are minimal and only show that the intergration
works. Exhaustive formatting tests are done with RegisterFlags itself.

Example:
```
(lldb) register info cpsr
       Name: cpsr
       Size: 4 bytes (32 bits)
    In sets: general (index 0)

| 31 | 30 | 29 | 28 | 27-26 | 25  | 24  | 23  | 22  | 21 | 20 | 19-13 |  12  | 11-10 | 9 | 8 | 7 | 6 | 5 |  4  | 3-2 | 1 | 0  |
|----|----|----|----|-------|-----|-----|-----|-----|----|----|-------|------|-------|---|---|---|---|---|-----|-----|---|----|
| N  | Z  | C  | V  |       | TCO | DIT | UAO | PAN | SS | IL |       | SSBS |       | D | A | I | F |   | nRW | EL  |   | SP |
```

LLDB limits the max terminal width to 80 chars by default.
So to get that full width output you will need to change the "term-width"
setting to something higher.

Reviewed By: jasonmolenda

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

This commit adds functionality to the Apple Accelerator table allowing iteration
over all elements in the table.

Our iterators look like streaming iterators: when we increment the iterator we
check if there is still enough data in the "stream" (in our case, the blob of
data of the accelerator table) and extract the next entry. If any failures
occur, we immediately set the iterator to be the end iterator.

Since the ultimate user of this functionality is LLDB, there are roughly two
iteration methods we want support: one that also loads the name of each entry,
and one which does not. Loading names is measurably slower (one order the
magnitude) than only loading DIEs, so we used some template metaprograming to
implement both iteration methods.

Depends on D153066

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

This patch implements IR combines to convert intrinsics used for _m C/C++ builtins
which take an all active predicate to their equivalent _u intrinsic.

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

The intent of this patch is to make upper halves of SPE SuperRegs(s0,..,s31)
as artificial regs, similar to how X86 has done it.
And emit store /reload instructions for the required halves.

PR : https://github.com/llvm/llvm-project/issues/57307

Reviewed By: jhibbits

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

This patch changes emitSLEB128IntValue with emitULEB128IntValue
for length part of address range of DW_RLE_start_length kind. DWARFv5
standard:

DW_RLE_start_length
This is a form of bounded range entry that has one target address operand
value and an unsigned LEB128 integer length operand value.

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

This patch adds a check for uninitialized subobjects of global variables that are record arrays.
e.g. `constexpr Foo f[2];`

Reviewed By: tbaeder

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

As a follow up of https://reviews.llvm.org/D153250, this path uses the
explicit symbol registration mechanism of the execution engine in the
CRunnerUtils library.

Reviewed By: mehdi_amini

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

I missed these review comments on https://reviews.llvm.org/D152917
before landing it.

This will be used by the "register info" command to show
the layout of register contents. For example if we have
these fields coming in from XML:
```
<field name="D" start="0" end="7"/>
<field name="C" start="8" end="15"/>
<field name="B" start="16" end="23"/>
<field name="A" start="24" end="31"/>
```
We get:
```
| 31-24 | 23-16 | 15-8 | 7-0 |
|-------|-------|------|-----|
|   A   |   B   |  C   |  D  |
```
Note that this is only the layout, not the values.
For values, use "register read".

The tables' columns are center padded (left bias
if there's an odd padding) and will wrap if the terminal width
is too low.

```
| 31-24 | 23-16 |
|-------|-------|
|   A   |   B   |

| 15-8 | 7-0 |
|------|-----|
|  C   |  D  |
```

This means we match the horizontal format seen in many architecture
manuals but don't spam the user with lots of misaligned text when the
output gets very long.

Reviewed By: jasonmolenda

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

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

The root cause for the issue is that we think the associated constraints
from the 'same' declaration in different module units are different
incorrectly. Since the constraints doesn't know anything about decls and
modules, we should fix the problem by getting the associated constraints
from the exactly the same declarations from different modules.

This adds a new command that will show all the information lldb
knows about a register.
```
(lldb) register info s0
       Name: s0
       Size: 4 bytes (32 bits)
Invalidates: v0, d0
  Read from: v0
    In sets: Floating Point Registers (index 1)
```

Currently it only allows a single register, and we get the
information from the RegisterInfo structure.

For those of us who know the architecture well, this information
is all pretty obvious. For those who don't, it's nice to have it
at a glance without leaving the debugger.

I hope to have more in depth information to show here in the future,
which will be of wider use.

Reviewed By: jasonmolenda

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

This reverts commit 1b9b78fd.

There are spurious test failures on the ml-* bots and some of the ARM
builders are complaining about shm_open being missing. Pulling this
commit so that I can investigate after I sleep.

This is intended to behave like GCC's `-mcmodel=extreme`.

Technically the true GCC equivalent would be `-mcmodel=large` which is
not yet implemented there, and we probably do not want to take the
"Large" name until things settle in GCC side, but:

* LLVM does not have a `CodeModel::Extreme`, and it seems too early to
  have such a variant added just for enabling LoongArch; and
* `CodeModel::Small` is already being used for GCC `-mcmodel=normal`
  which is already a case of divergent naming.

Regarding the codegen, loads/stores immediately after a PC-relative
large address load (that ends with something like `add.d $addr, $addr,
$tmp`) should get merged with the addition into corresponding `ldx/stx`
ops, but is currently not done. This is because pseudo-instructions are
expanded after instruction selection, and is best fixed with a separate
change.

Reviewed By: SixWeining

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

- Correctly handle OpNum == 0 (auto select operand)
- Implement MCExpr overload

Reviewed By: rafauler

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

Reviewed By: rafauler

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

Reviewed By: rafauler

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

This patch introduces the SubprocessMemory class to llvm-exegesis. This
class contains several utilities that are needed for managing memory to
set up an execution environment for memory annotations.

Reviewed By: courbet

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

This avoids bazel builds failing after commit bba2b656 because libmlir_test_spirv_cpu_runner_c_wrappers.so registers the same runner functions twice.

More precisely, this problem only shows up internally at Google because the bazel build does not have that target.

Either way though, it's better to IWYU.

This patch introduces the subprocess executor mode. Currently, this new
mode doesn't do anything fancy, just executing the same code that the
inprocess executor would do, but within a subprocess. This sets up the
ability to add in many more memory-related features in the future.