For tests marked as "USE_SYSTEM_STDLIB", the expectation is that the
system's standard library should be used. However, the implementation of
this flag is such that we simply don't pass _any_ libcxxx-related flags
to Clang; in turn, Clang will use its defaults.

For a Clang/Libcxx pair compiled together, Clang defaults to:
1. The headers of the sibling libcxx.
2. The libraries of the system.

This mismatch is actually a bug in the driver; once fixed, however, (2)
would point to the sibling libcxx as well, which is _not_ what test
authors intended with the USE_SYSTEM_STDLIB flag.

As such, this patch explicitly sets a path to the system's libraries.
This change is done only in Apple platforms so that we can test this
works in this case first.

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

This patch adds the OffloadEntriesInfoManager to the OpenMPIRBuilder, and
allows the OffloadEntriesInfoManager to access the Configuration in the
OpenMPIRBuilder.  With the shared Config there is no risk for inconsistencies,
and there is no longer the need for clang to have a separate
OffloadEntriesInfoManager.

Reviewed By: jdoerfert

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

We can simply push them down the existing call slowpath with some minor changes to how we compute the size argument.

[HWASAN] Disable unexpected_format_specifier_test because HWASAN doesn't provide a printf interceptor

Reviewed By: vitalybuka

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

I noticed, when examining the generated Asm Matcher table, that some of
these custom immediate operands are missing, and so we are not parsing
some hint aliases into the correct MCInst.

Where this becomes apparent is when you parse e.g. `hint #7` into an
MCInst - without these cases, it becomes the MCInst `(HINT 17)`, which
will always be printed as `hint #17`. With these cases, it becomes the
MCInst `XPACLRI`, which will be printed as `xpaclri` with pauth, or
`hint #17` without, matching how `xpaclri` is parsed.

We only handle some specific hint aliases in this manner, usually where
these hints have specific effects that need to be modelled for accurate
code-generation. Otherwise, we just use the normal `InstAlias` system
to have the aliases parsed into a `(HINT N)` MCInst.

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

Fix a regresion introduced by D124351.
Attributes of lambda call operator were evaluated in the
context of the closure object type rather than its operator,
causing an assertion failure.

This was because we temporarily switch to the class lambda to
produce the mangling of the lambda, but we stayed in that
context too long.

Reviewed By: eandrews, aaron.ballman

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

This adds support for scalable vector types - at least far enough to get basic load and store cases working. It turns out that load/store without origin tracking already worked; I apparently got that working with one of the pre patches to use TypeSize utilities and didn't notice. The code changes here are required to enable origin tracking.

For origin tracking, a 4 byte value - the origin - is broadcast into a shadow region whose size exactly matches the type being accessed. This origin is only written if the shadow value is non-zero. The details of how shadow is computed from the original value being stored aren't relevant for this patch.

The code changes involve two related primitives.

First, we need to be able to perform that broadcast into a scalable sized memory region. This requires the use of a loop, and appropriate bound. The fixed size case optimizes with larger stores and alignment; I did not bother with that for the scalable case for now. We can optimize this codepath later if desired.

Second, we need a way to test if the shadow is zero. The mechanism for this in the code is to convert the shadow value into a scalar, and then zero check that. There's an assumption that this scalar is zero exactly when all elements of the shadow value are zero. As a result, we use an OR reduction on the scalable vector. This is analogous to how e.g. an array is handled. I landed a bunch of cleanup changes to remove other direct uses of the scalar conversion to convince myself there were no other undocumented invariants.

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

Differential Revision: https://reviews.llvm.org/D144445
Reviewed By: nikic

fix: wrong arrow

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

tweak: test

This patch fixes an issue whereby a constexpr class member which is
mapped to the device is being optimized out thus leading to a runtime
error.

Patch: https://reviews.llvm.org/D146552

Fix regression introduced by https://reviews.llvm.org/D123446

Reviewed By: tianshilei1992

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

SVE and MTE both require a CPU with that feature before
you can use the other options, but we only added the "max"
cpu when SVE was enabled too.

This patch adds an `llc` option `-mroptr` to specify storage locations for constant pointers on AIX.

When the `-mroptr` option is specified, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. Otherwise, by default, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage.

https://reviews.llvm.org/D144190 enables the `-mroptr` option for `clang`.

Reviewed By: hubert.reinterpretcast, stephenpeckham, myhsu, MaskRay, serge-sans-paille

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

This reverts commit 8482b238.

I usually would fold this into the assert, but the comment there
suggests side effects. NFC.

ModuleMap.cpp:938:9: error: unused variable 'MainFile' [-Werror,-Wunused-variable]
  auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());

Another step toward #53419 - this is also another step towards expanding MatchVectorAllZeroTest to match any pair of vectors and merge EmitAVX512Test into it.

ConcurrentHashTable - is a resizeable concurrent hashtable.
The range of resizings is limited up to x2^32. The hashtable allows only concurrent insertions.

Concurrent hashtable is necessary for the D96035 patch.

Reviewed By: JDevlieghere

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

A fully fledged LLVM inliner will require a lot of logic. Since
`LLVMDialect.cpp` is large enough as it is, preemptively outline the
inlining logic into a separate `.cpp` file. This will also allow us to
add a `DEBUG_TYPE` for debugging the inliner.

The name `LLVMInlining` was chosen over `LLVMInlinerInterface` to keep
the option open for exposing inlining functionality even when not
invoked through the `DialectInlinerInterface`.

Depends on D146616

Reviewed By: gysit

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

`llvm/utils/TableGen/GlobalISel` should be exported.

FYI, after D144351,`tablegen_tests` behaved same
as `llvm-tblgen -print-records`.
It suceeded because stdin is `/dev/null`.

c39dd7c1 missed a needed change to the
llvm-objdump test.

c39dd7c1 missed the appropriate change
to clang/test/Driver/ricv-arch.c.

We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).

This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.

Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).

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

Revert rG6aa7cc03 - "[X86] LowerVectorAllZero - add 512-bit support with AVX512 vptestnmd+kortestw patterns"

Reverted - I need to adjust the implementation so we can properly refactor it into a "LowerVectorAllEqual" function

Commit cc2457ca changed the default but forgot to update the help message.

Implement MC support for the recently ratified RV64E base instruction
set.

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

Another step toward #53419 - this is also another step towards expanding MatchVectorAllZeroTest to match any pair of vectors and merge EmitAVX512Test into it.

Private headers inside umbrella files shouldn't be marked as unused.

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

This reverts commit 201fdef4.

There was an issue found in post-commit by:
https://lab.llvm.org/buildbot/#/builders/91/builds/15272

NFC

It doesn't make sense on ARM and using default 0 fill is compatible
with MSVC.

(It's more noticeable ARM64EC targets, where additional padding mixed
with alignment is used for entry thunk association, so there are more
gaps).

Reviewed By: mstorsjo

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

We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section that does not really fit GNU format.
This patch implements writing in COFF format (as in, it's what archive
reader considers as K_COFF). This mostly requires symbol emitting symbol
map. Note that, just like in case of MSVC, symbols are de-duplicated in
both usual symbol table and the new symbol map.

Reviewed By: efriedma

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

Having string table in members vector does not fit later patches in
this series. Symbol map needs to refer to objects' offsets, but string
table should not be referenced. Also for ARM64EC, the new <ECSYMBOLS>
table is inserted after string table.

Reviewed By: efriedma

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

In preparation for COFF archives support.

Reviewed By: efriedma

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

Since D141386 has changed the return value of !range from IUB to poison,
metadata !range shouldn't be preserved even if K dominates J.

If this patch was accepted, I plan to adjust metadata !nonnull as well.
BTW, I found that metadata !noundef is not handled in combineMetadata,
is this intentional?

Reviewed By: nikic

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