The generated version of the file is already installed -- we shouldn't
install the pre-generation version of the file.

This is an LLD-specific option. We have enforced double-dash forms for
other options (reduce collision with short options) but missed this one.

GFX10 image instructions use one or more address operands starting at
vaddr0, instead of a single vaddr operand, to allow for NSA forms.

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

Use the algorithm from AMDGPUCodeGenPrepare::expandDivRem32.

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

Use the algorithm from AMDGPUCodeGenPrepare::expandDivRem32.

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

Fix the division/remainder algorithm by adding a second quotient
refinement step, which is required in some cases like
0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212).

Also document, rewrite and simplify it by ensuring that we always have a
lower bound on inv(y), which simplifies the UNR step and the quotient
refinement steps.

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

Reviewers: efriedma, fhahn, reames, kmclaughlin, sdesmalen

Reviewed By: sdesmalen

Subscribers: tschuett, hiraditya, rkruppe, psnobl, dantrushin, llvm-commits

Tags: #llvm

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

It's sufficient to sniff the platform we're running on using the compiler
macros -- we don't need to run any code.

Thanks to @lewissbaker who pointed out the unnecessary condition in
https://reviews.llvm.org/D81954#inline-756872. Since this codepath does not
make use of `swap` anyway (that codepath is a different branch), we can safely
remove this condition and produce better codegen when all types are nothrow
movable but are potentially-throwing swappable.

See codegen in https://gcc.godbolt.org/z/uDFZjz

Reviewed By: ldionne, #libc

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

[X86] Enabled a bunch of 64-bit Interlocked* functions intrinsics on 32-bit Windows to match recent MSVC

This enables _InterlockedAnd64/_InterlockedOr64/_InterlockedXor64/_InterlockedDecrement64/_InterlockedIncrement64/_InterlockedExchange64/_InterlockedExchangeAdd64/_InterlockedExchangeSub64 on 32-bit Windows

The backend already knows how to expand these to a loop using cmpxchg8b on 32-bit targets.

Fixes PR46595

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

The other backends don't know what this feature is and print a
message to stderr.

I recently tried to rework some target feature stuff in X86 and
this unknown feature tripped an assert I added.

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

In the absence of TLS relaxation (rewrite of code sequences),
there is still an applicable optimization:

[gd]: General Dynamic: resolve DTPMOD to 1 and/or resolve DTPOFF statically

All the other relaxations are only performed when transiting to
executable (`!config->shared`).
Since [gd] is handled differently, we can fold `!config->shared` into canRelax
and simplify its use sites. Rename the variable to reflect to new semantics.

Reviewed By: grimar, psmith

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

This patch extends D58439 (`llvm/test/{yaml2obj,obj2yaml}/**/*.yaml`) and runs all
`llvm/test/**/*.yaml`

Many directories have configured `.yaml` (see the deleted lit.local.cfg
files). Yet still some don't configure .yaml and have caused stale tests:

* 8c5825be test/llvm-readobj
* bdc3134e test/ExecutionEngine

Just hoist .yaml to `llvm/test/lit.cfg.py`. Also delete .cxx which is
not used.  The number of tests running on my machine increases from 38304 to 38309.
The list of new tests:

```
ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_none.yaml
Object/archive-error-tmp.txt
tools/llvm-ar/coff-weak.yaml
tools/llvm-readobj/ELF/verneed-flags.yaml
tools/obj2yaml/COFF/bss.s
```

Reviewed By: grimar, jhenderson, rupprecht

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

... to customize the tombstone value we use for an absolute relocation
referencing a discarded symbol. This can be used as a workaround when
some debug processing tool has trouble with current -1 tombstone value
(https://bugs.chromium.org/p/chromium/issues/detail?id=1102223#c11 )

For example, to get the current built-in rules (not considering the .debug_line special case for ICF):

```
-z dead-reloc-in-nonalloc='.debug_*=0xffffffffffffffff'
-z dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe
-z dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe
```

To get GNU ld (as of binutils 2.35)'s behavior:

```
-z dead-reloc-in-nonalloc='*=0'
-z dead-reloc-in-nonalloc=.debug_ranges=1
```

This option has other use cases. For example, if we want to check
whether a non-SHF_ALLOC section has dead relocations.
With this patch, we can run a regular LLD and run another with a special
-z dead-reloc-in-nonalloc=, then compare their output.

Reviewed By: thakis

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

Summary:
When there are errors in the evaluation of every cosubscript expression in a
coindexed object, the compiler would crash.  I fixed this by just checking to
see if there were errors in the evaluation of the cosubscripts before
constructing the `DataRef` for the coindexed object.

Reviewers: klausler, tskeith, DavidTruby

Subscribers: llvm-commits

Tags: #llvm

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

This patch let lambda be host device by default and adds diagnostics for
capturing host variable by reference in device lambda.

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

[RecordLayout] Fix ItaniumRecordLayoutBuilder so that is grabs the correct bases class offsets from the external source

Currently the ItaniumRecordLayoutBuilder when laying out base classes has the virtual
and non-virtual bases mixed up when pulling the base class layouts from the external source.

This came up in an LLDB bug where on arm64 because of differences in how it deals with
tail padding would layout the bases differently without the correct layout from the
external source (LLDB). This would result in some fields being off by 4 bytes.

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

This removes existing code duplication and allows us to
assert that we are handling the expected cases.

We have a list of outstanding bugs that could benefit by
handling truncated source values, so that's a possible
addition going forward.

Future patches will extend this so declutter combineVectorPack before we start.

Fixes tests under NPM in Transforms/Util/PredicateInfo.

by default.

sample-profile-top-down-load is an internal option which can enable top-down
order of inlining and profile annotation in sample profile load pass. It was
found to be beneficial for better profile annotation.

Recently we found it could also solve some build time issue. Suppose function
A has many callsites in function B. In the last release binary where sample
profile was collected, the outline copy of A is large because there are many
other functions inlined into A. However although all the callsites calling A
in B are inlined, but every inlined body is small (A was inlined into B
before other functions are inlined into A), there is no build time issue in
last release.

In an optimized build using the sample profile collected from last release,
without top-down inlining, we saw a case that A got very large because of
inlining, and then multiple callsites of A got inlined into B, and that led
to a huge B which caused significant build time issue besides profile
annotation issue.

To solve that problem, the patch enables the flag
sample-profile-top-down-load by default. sample-profile-top-down-load can
have better performance when it is enabled together with
sample-profile-merge-inlinee so in this patch we also enable
sample-profile-merge-inlinee by default.

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

Revision e1de2773 provided support for
accepting integer registers in inline asm i.e.

__asm("lhi %r0, 5") -> lhi %r0, 5
__asm("lhi 0, 5") -> lhi 0,5

This patch aims to extend this support to instructions which compute
addresses as well. (i.e instructions of type BDMem and BD[X|R|V|L]Mem)

Author: anirudhp

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

Summary:
Almost all uses of these iterators, including implicit ones, really
only need the const variant (as it should be). The only exception is
in NewGVN, which changes the order of dominator tree child nodes.

Change-Id: I4b5bd71e32d71b0c67b03d4927d93fe9413726d4

Reviewers: arsenm, RKSimon, mehdi_amini, courbet, rriddle, aartbik

Subscribers: wdng, Prazek, hiraditya, kuhar, rogfer01, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, vkmr, Kayjukh, jurahul, msifontes, cfe-commits, llvm-commits

Tags: #clang, #mlir, #llvm

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

This reverts commit 37afd99c.

There used to be a workaround where we'd pretend that GCC 5 didn't support
C++14 because it doesn't implement it properly. Since that workaround has
been removed (in 1eb211ad), we need to mark a few individual tests as
failing with GCC 5.

 Fixes 52 check-llvm tests under NPM.

Reviewed By: hans

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

[clang] Fix a crash when passing a C structure of incompatible type to a function with a reference parameter.

__builtin_va_*() and __builtin_ms_va_*() are declared as functions with a
parameter of reference type.

This patch fixes a crash when using these functions in C where an argument
of structure type is incompatible with the parameter type.

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

Reviewed By: riccibruno

Patch by: Aleksandr Platonov <platonov.aleksandr@huawei.com>

There's no reason to introduce a new option for the NPM.
The various PGO options are shared in this manner.

Reviewed By: echristo

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

Patch eliminates string length calculation when lexing a token. Speedup can be up to
1000x.

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

This cleans up the stack allocated by a @llvm.call.preallocated.setup.
Should either call the teardown or the preallocated call to clean up the
stack. Calling both is UB.

Add LangRef.

Add verifier check that the token argument is a @llvm.call.preallocated.setup.

Reviewed By: efriedma

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