The values are small so the difference doesn't matter, but the
consuming function is defined to take 'unsigned'.

ASMPrinter was relying on feature bits to setup extra SGRPs in the knerel
descriptor for the xnack_mask. This was broken for the dynamic XNACK "any" TID
setting which could cause user SGPRs to be clobbered if the number of SGPRs
reserved was near a granulated block boundary.

When XNACK was enabled this worked correctly in the ASMParser which meant some
kernels were only failing without "-save-temps".

Fixes: SWDEV-382764

Reviewed By: kzhuravl

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

This speeds up section lookup by name.

This change was motivated by poor performance of a testcase while trying to fix
the NoAlloc lifetime patch that was originally landed as 2cc64df0. The
NoAlloc lifetime patch causes ELF non-SHF_ALLOC sections to be given a JITLink
Section (previously they were skipped), and the
llvm/test/ExecutionEngine/JITLink/X86/ELF_shndex.s testcase creates > 64k
non-SHF_ALLOC sections, each of which now needs to be checked to ensure that its
name does not clash. Moving to a DenseMap allows us to implement this check
efficiently.

This adds debug info support for
- `thread_local` global variables, both in non-PIC and PIC modes
- (non-thread_local) Global variables in PIC mode

The former needs to read the value from an offset relative to
`__tls_base` and the latter an offset from `__memory_base`. The code for
doing this overlaps with some of the existing code to add
`__stack_pointer` global, so this adds a new member function to add a
a global in `TI_GLOBAL_RELOC` mode and use it in all three places.

Split DWARF support is currently patchy at best, because the index for
`__tls_base` is not fixed after dynamic linking. The preexisting split
DWARF support for `__stack_pointer` relies on that in practice it is
always index 0. This does similar hardcoding for `__tls_base` and
`__memory_base`, but `__tls_base`'s index in dynamic linking is not
fixed now (See
https://github.com/llvm/llvm-project/blob/19afbfe33156d211fa959dadeea46cd17b9c723c/lld/wasm/Driver.cpp#L786-L823
for details), TLS + dynamic linking will not work at the moment.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1416702.

Reviewed By: dschuff

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

We have a good comment on `TEE` transformation in `RegStackify`:
https://github.com/llvm/llvm-project/blob/547e3456660000a16fc5c2a2f819f1a2b5d35b5d/llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp#L613-L632

And I think it can be helpful to have some more comments on how the
`TEE`s created in `RegStackify` are converted into `LOCAL_TEE`s.

Variable `OldReg` is changed to `DefReg` to be consistent with
`RegStackify`'s comment.

Reviewed By: tlively

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

When making `DBG_VALUE`/`DBG_VALUE_LIST` instructions undefined, there
is a method that takes care of it so we don't need to do it manually.
This changes the test because previously we are converting
`DBG_VALUE_LIST`s into `DBG_VALUE $noreg` but now we leave
`DBG_VALUE_LIST` but set it to undef by turning all its register
operands `$noreg`. The effect is the same.

Reviewed By: dschuff

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

The current implementation output the LLVM formatted heading for group
sections, which was not valid JSON. This patch provides two small
customization points that allow the heading to vary between the two
implementations, and another that allows the section members to be
output as valid JSON objects.

Reviewed By: jhenderson

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

Reviewed By: dschuff, asb

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

Prior to this patch, the JSON output would emit an invalid key from the
shared LLVM implementation. This caused llvm-readobj to output invalid
JSON. This patch introduces a small helper function to print the
relocation information differently between the LLVM and JSON formats.

Before this patch:

```
    "Relocations": [Section (2) .rel.text {

      {
        "Relocation": {
          "Offset": 0,
          "Type": {
            "Value": "R_X86_64_NONE",
            "RawValue": 0
          },
          "Symbol": {
            "Value": "rel_0",
            "RawValue": 1
          }
        }
      },
      ...

```

After this patch:

```
   "Relocations": [
      {
        "SectionIdx": 2,
        "Relocs": [
          {
            "Relocation": {
              "Offset": 0,
              "Type": {
                "Name": "R_X86_64_NONE",
                "Value": 0
              },
              "Symbol": {
                "Name": "rel_0",
                "Value": 1
              }
            }
          },
          ...
```

Reviewed By: jhenderson

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

[TSan] Make sure we only collect non-TSan frames for memory operations r=dvyukov,rsundahl,thetruestblue,wrotki,kubamracek!

A previous change [1] moved retrieval of the caller PC
(`__builtin_return_address(0)` via `CALLERPC`) from an
interface-boundary function into a shared helper function
`ExternalAccess`.  If this function does not get inlined, we fail to
collect the appropriate caller PC for the "TSan interface boundary".

[1] https://reviews.llvm.org/D32360

rdar://78489600

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

Matches the CMake build:
https://github.com/llvm/llvm-project/blob/93c1a5f3ddd41e0ec09f38ab0045bd5e92199fd5/compiler-rt/CMakeLists.txt#L343
(we always use API level 29).

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

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

Today the JSON uses `Value` and `RawValue` when printing `Flags`, when really
the `Value` field is always the name of an Enum variant, and `RawValue` is its
underlying numeric value. Similarly, we rename the `RawFlags` key to `Value`,
to match the new scheme. This also allows JSON parsing to use consistent logic
for `Flag` types.

Reviewed By: jhenderson

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

The existing JSON incorrectly outputs line breaks and other invalid JSON.

Example Before this patch:

```
...
"Relocations":[Section (9) .rela.dyn {
  0xA3B0 R_X86_64_RELATIVE - 0x43D0
  0xA3B8 R_X86_64_RELATIVE - 0x4A30
...
```

Example After this patch:

```
...
"Relocations":[Section (9) .rela.dyn {
{"Relocation":{"Offset":41904,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17360}},
{"Relocation":{"Offset":41912,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":18992}},
{"Relocation":{"Offset":41920,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17440}},
...
```

Note there are still issues with the Section, but each Relocation is
now a valid JSON object that can be parsed. Future patches will address
the issues regarding JSON output for the Section.

Reviewed By: jhenderson

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

Today, the LLVM output uses special handling when the Other field is 0.
This output makes sense for a command line utility that a human will
read, but JSON is a machine readable format, so being consistent is more
important. Prior to this change, any consumer of the JSON output would
need to handle the Other field specially, since the structure of the
JSON would no longer be consistent.

Changes to JSON output when Other flag == 0:
```
"Other": 0,   ->   "Other": {
                      "RawFlags": 0,
                       "Flags": []
                    },
```

There are no changes to when Other flag != 0:
```
"Other": {        ->   "Other": {
  "RawFlags": 1,          "RawFlags": 1,
  "Flags": [              "Flags": [
      ...                     ...
  ]                       ]
},                     },
```

This patch adds a overload for the JSONELFDumper's printSymbol() method,
that uses consistent output formatting, regardless of the value of the
Other field.

Depends on D137092

Reviewed By: jhenderson

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

These calls were added in D141222.

Reviewed By: #libc, ldionne

Spies: ldionne, libcxx-commits, smeenai, mikhail.ramalho

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

Since all ELFDumper implementations will require the same logic when
dealing with Other Flags, we move the logic into a helper so that it can
be easily reused across implementations.

Reviewed By: jhenderson

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

There were two major problems with the tests.

First, with the pointer size being 32 bit and the original IVs also being 32 bit, almost all of the positive tests were actually unsound.  An upcoming change will add the appropriate safety check, but the test diffs are really hard to understand without switching the tests to 64 bit pointers first.

Second, checking debug messages for failures is a major bad practice.  This should not have been accepted in review at all.  The reason is that it makes the *order* of legality checks visibile and modifying any of them becomes annoying and tedious.

This reverts commit 03aa02ad.

Reverting due to bot failures:
https://lab.llvm.org/buildbot/#/builders/247/builds/2653

Reviewed By: ThomasRaoux

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

We're not checking the attributes themselves, so hardcoded attribute numbers
only make the tests more fragile, without improving the testing.

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

We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.

As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.

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

On Android, mallinfo2 is an alias of mallinfo, which results
in errors if we try to define both.

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

This reverts commit 5f66348e.

SerializeToCubin depends on CUDA at *runtime* which is undesirable for MLIR's
general use case, as compilation should be doable on any host, regardless of
whether it has a GPU.

SerializeToCubin is needed to run some GPU tests, so when we build mlir-opt,
SerializeToCubin pass is linked in directly into mlir-opt.

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

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

If an inlined kernel is called in a loop, the launch point alloca would
lead to increasing stack usage every time the kernel is invoked. This
could make the application run out of stack space and crash. This problem
is fixed by using the alloca insertion point while creating the alloca instruction.

Fixes https://github.com/llvm/llvm-project/issues/60602

Reviewed By: jdoerfert

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

Since P0857, part of C++20, a *lambda-expression* can contain a
*requires-clause* after its *template-parameter-list*.

While support for this was added as part of
eccc734a, one specific case isn't
handled properly, where the *requires-clause* consists of an
instantiation of a boolean variable template. This is due to a
diagnostic check which was written with the assumption that a
*requires-clause* can never be followed by a left parenthesis. This
assumption no longer holds for lambdas.

This diagnostic check would then attempt to perform a "recovery", but it
does so in a valid parse state, resulting in an invalid parse state
instead!

This patch adds a special case when parsing requires clauses of lambda
templates, to skip this diagnostic check.

Fixes https://github.com/llvm/llvm-project/issues/61278
Fixes https://github.com/llvm/llvm-project/issues/61387

Reviewed By: erichkeane

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

Differential revision: https://reviews.llvm.org/D146186

This reverts commit 2cc64df0 while I investigate
bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/23081).

This cleans up the test a bit and enables it to run on apple silicon
machines.

The original MemDeallocPolicy had two options:
* Standard: allocated memory lives until deallocated or abandoned.
* Finalize: allocated memory lives until all finalize actions have been run,
            then is destroyed.

This patch introduces a new 'NoAlloc' option. NoAlloc indicates that the
section should be ignored by the JITLinkMemoryManager -- the memory manager
should allocate neither working memory nor executor address space to blocks in
NoAlloc sections. The NoAlloc option is intended to support metadata sections
(e.g. debug info) that we want to keep in the graph and have fixed up if
necessary, but don't want allocated or transmitted to the executor (or we want
that allocation and transmission to be managed manually by plugins).

Since NoAlloc blocks are ignored by the JITLinkMemoryManager they will not have
working memory allocated to them by default post-allocation. Clients wishing to
modify the content of a block in a NoAlloc section should call
`Block::getMutableMemory(LinkGraph&)` to get writable memory allocated on the
LinkGraph's allocator (this memory will exist for the lifetime of the graph).
If no client requests mutable memory prior to the fixup phase then the generic
link algorithm will do so when it encounters the first edge in any given block.

Addresses of blocks in NoAlloc sections are initialized by the LinkGraph
creator (a LinkGraphBuilder, if the graph is generated from an object file),
and should not be modified by the JITLinkMemoryManager. Plugins are responsible
for updating addresses if they add/remove content from these sections. The
meaning of addresses in NoAlloc-sections is backend/plugin defined, but for
fixup purposes they will be treated the same as addresses in Standard/Finalize
sections. References from Standard/Finalize sections to NoAlloc sections are
expected to be common (these represent metadata tracking executor addresses).
References from NoAlloc sections to Standard/Finalize sections are expected to
be rare/non-existent (they would represent JIT'd code / data tracking metadata
in the controller, which would be surprising). LinkGraphBuilders and specific
backends may impose additional constraints on edges between Standard/Finalize
and NoAlloc sections where required for correctness.

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

Reviewed By: reames

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

This can prevent unnecessarily hoisting out of loops.

Test case cribbed from AArch64.

I also intend to make them rematerializable.

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

Test case for D146314.

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