lib/Support/ThreadLocal.cpp has been uncompilable since rL158346 (2012-06) when
`data` became a char array. The error looks like
```
...llvm/lib/Support/Unix/ThreadLocal.inc:66:57: error: array type 'char[8]' is not assignable
void ThreadLocalImpl::setInstance(const void* d) { data = const_cast<void*>(d);}
```

Tested on an example callstack with misplaced binaries from Android.
Tested Regex against callstack without Build ID to confirm it still works.

Reviewed By: eugenis

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

The new PM been the default for a while and we're in the process of removing the legacy PM optimization pipeline.

This has been the default for a while and we're in the process of removing the legacy PM optimization pipeline.

This has been the default for a while and we're in the process of removing the legacy PM optimization pipeline.

When scanning a macro expansion to examine it as a candidate enum,
first strip off arbitrary matching parentheses from the outside in,
then examine what remains to see if it is Lit, +Lit, -Lit or ~Lit.
If not, reject it as a possible enum candidate.

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

Fixes #54843

Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you're waiting for the next line to be executed in the REPL.

This patch disables reporting of progress events when in REPL mode.

rdar://91502950

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

The test is already simplified, and I'm not sure how
to write a test to exercise the new clause. But it
protects the 2-bit pattern from miscompiling as noted
in D123453.

https://alive2.llvm.org/ce/z/QPyVfv
(If we managed to fall into the mul transform, it
would wrongly create a zero on this pattern.)

Normalize some of the division and inequality expressions used,
which can improve performance. Also deduplicate some of the
normalization functionality throughout the Presburger library.

Reviewed By: Groverkss

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

{D123302} got me looking deeper at `includeInSymtab`. I thought it was a
little odd that there were excluded (live) symbols for which
`includeInSymtab` was false; we shouldn't have so many different ways to
exclude a symbol. As such, this diff makes the `L`-prefixed-symbol
exclusion code use `includeInSymtab` too. (Note that as part of our
support for `__eh_frame`, we will also be excluding all `__eh_frame`
symbols from the symtab in a future diff.)

Another thing I noticed is that the `emitStabs` code never has to deal
with excluded symbols because `SymtabSection::finalize()` already
filters them out. As such, I've updated the comments and asserts from
{D123302} to reflect this.

Reviewed By: #lld-macho, thakis

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

When making the subtract implementation non-recursive, tail calls were
implemented by incrementing the level but not pushing a frame, and returning
was implemented as returning to the level corresponding to the number of frames in the stack.

This is incorrect, as there could be a case where we tail-recurse at `level`,
and then recurse at `level + 1`, pushing a frame. However, because the previous
frame was missing, this new frame would be interpreted as corresponding to
`level` and not `level + 1`. Fix this by removing the special handling of tail
calls and just doing them as normal recursion, as this is the simplest correct
implementation and handling them specifically would be a premature optimization.

The impact of this bug is only on performance as this can only lead to
unnecessary subtractions of the same disjuncts multiples times. As subtraction
is idempotent, and rationally empty disjuncts are always discarded, this
does not affect the output, so this patch does not include a regression test.
(This also does not affect termination.)

Reviewed By: Groverkss

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

Reviewed By: dexonsmith

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

The AMDGPUISD::SETCC node is like ISD::SETCC, but returns a lane mask
instead of a per-lane boolean. The lane mask is uniform.

This improves instruction selection for code patterns like
ctpop(ballot(x)), which can now use an S_BCNT1_* instruction instead
of V_BCNT_*.

GlobalISel already selects scalar instructions (an earlier commit
added a test case)..

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

This patch contains several ODS-level optimizations to attribute getters and getting.

1. OpAdaptors, when provided a DictionaryAttr, will instantiate an OperationName so that adaptor attribute getters can used cached identifiers.
2. Verifiers will take advantage of attributes stored in sorted order to get all required (non-optional, non-default valued, and non-derived) attributes in one pass over the attribute dictionary and verify that they are present.
3. ODS-generated attribute getters will use "subrange" lookup. Because the attributes are stored in sorted order and ODS knows which attributes are required, the number of required attributes less than and greater than each attribute can be computed. When searching for an attribute, the ends of the search range can be dropped.

Reviewed By: jpienaar

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

IMO when user provide unroll pragma, compiler should always respect it.
It is not clear to me why loop unroll pass currently ensure that the
unrolled loop size is limited by PragmaUnrollThreshold.

Reviewed By: Meinersbur

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

- Split GlobalRecord into two distinct types to be able to introduce
has_function_signature type trait.
- Add has_function_signature type trait.
- Serialize function signatures as part of serializeAPIRecord for
records that are known to have a function signature.

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

The Android platform does not have ndk-version.h, but it will always
have up-to-date libc headers, so it does not need any compatibility
code intended for past versions of NDK_MAJOR. If ndk-version.h is missing,
assume NDK_MAJOR is (conceptually) infinite

Bug: https://buganizer.corp.google.com/issues/222341313
Test: None

lib.exe by default exits successfully without writing an output
file when no inputs are passed. llvm-lib has the same behavior,
for compatibility.

This behavior interacts poorly with build systems: If a static
library target had no inputs, llvm-lib would not produce an output
file, causing ninja (or make, or a similar system) to successfully
run that step, but then re-run it on the next build.

After this patch, llvm-lib emits a warning in this case, that with
/WX can be turned into an error. That way, ninja (or make, or...)
will mark the initial build as failed.

People who don't like the warning can use /ignore:emptyoutput to
suppress it.

The warning also points out the existing flag /llvmlibempty which
forces creation of an empty .lib file (this is an extension to lib.exe).

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

This was added before Zve extensions were defined. I think users
should use Zve32x or Zve32f now. Though we will lose support for limiting
ELEN to 16 or 8, but I hope no one was using that.

Reviewed By: frasercrmck

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

Having an enum with names that contain the string representation
of their value doesn't add any value. We can just use the numbers.

Reviewed By: kito-cheng, frasercrmck

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

Move them to the only source file that included RegisterInfos_arm64.h
that actually used these variables.

This silences warnings like these:

    In file included from lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp:42:
    lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:790:35: warning: ‘g_register_infos_mte’ defined but not used [-Wunused-variable]
      790 | static lldb_private::RegisterInfo g_register_infos_mte[] = {
          |                                   ^~~~~~~~~~~~~~~~~~~~
    lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:787:35: warning: ‘g_register_infos_pauth’ defined but not used [-Wunused-variable]
      787 | static lldb_private::RegisterInfo g_register_infos_pauth[] = {
          |                                   ^~~~~~~~~~~~~~~~~~~~~~

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

We're just trying to canonicalize here and won't be using the constant
value returned.

The attached test changes are because we were previously commuting
a seteq X, (splat_vector 0) because we also have (sub 0, X). The
0 is larger than the element type so we don't detect it as a splat
without the AllowTruncation flag. By preventing the commute we are
able to match it to the vmseq.vx instruction during isel. We only
look for constants on the RHS in isel.

Reviewed By: spatel

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

On non-Windows platforms, get_temp_file_name() uses `mkstemp()`,
which picks a unique name and creates a file atomically. The
Windows implementation uses `_mktemp_s()`, which doesn't create the
file. The documentation of `_mktemp_s()` also says that by design,
the function uses the same pattern within a process, as long as that
file doesn't exist.

Thus previously, two consecutive calls to `get_temp_file_name()`
on Windows returned the same file name.

Try to create the suggested temp file with `_O_EXCL` (marking the
file name as already used for future calls to `_mktemp_s`) and retry
if we weren't able to exclusively create the file.

This fixes the test failures on Windows observed in D122257.

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

We build the library with C++20 anyways, so we can use noexcept directly.

Not all attributes have been added to phtread_attr_t in this patch. They
will be added gradually in future patches.

Reviewed By: lntue

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

Currently in Dexter, every step at which a DexExpectWatchValue/Type does
not have the correct value is printed on a separate line. This patch
reduces the size of the text output by instead printing each incorrect
result (i.e. each incorrect value seen, 'Variable optimized out', and so
on) on its own line, alongside a list of the steps at which that result
was seen. This makes for much less spam in the output when watches are
missing or wrong for many steps.

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

Details: The test previously expected a specific order of those symbols, which is not guaranteed (could change simply due to hashing changes, etc).
So we change it to explicitly sort the symbols before checking contents.

PR/53026

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

With one-use, we handle this via demanded-bits.
But We need to handle extra uses to improve issue #54750.

https://alive2.llvm.org/ce/z/aDYkPv

This reverts commit 42229b96.

This appears to cause crashes on multiple bots.

- Inline SymbolID hashing to header
- Don't collect references for symbols without a SymbolID
- Store referenced symbols, rather than separately storing decls and
  macros.
- Don't defer ref collection to end of translation unit
- Perform const_cast when updating reference counts (~0.5% saving)
- Introduce caching for getSymbolID in SymbolCollector. (~30% saving)
- Don't modify symbolslab if there's no definition location
- Don't lex the whole file to deduce spelled tokens, just lex the
  relevant piece (~8%)

Overall this achieves ~38% reduction in time spent inside
SymbolCollector compared to baseline (on my machine :)).

I'd expect the last optimization to affect dynamic index a lot more, I
was testing with clangd-indexer on clangd subfolder of LLVM. As
clangd-indexer runs indexing of whole TU at once, we indeed see almost
every token from every source included in the TU (hence lexing full
files vs just lexing referenced tokens are almost the same), whereas
during dynamic indexing we mostly index main file symbols, but we would
touch the files defining/declaring those symbols, and lex complete files
for nothing, rather than just the token location.

The last optimization is also a functional change (added test),
previously we used raw tokens from syntax::tokenize, which didn't
canonicalize trigraphs/newlines in identifiers, wheres
Lexer::getSpelling canonicalizes them.

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

Even if the GEP is not inbounds, the GEP will have provenance of
the global, and accessing past the extent of the global would be
undefined behavior.