As mentioned on D123678 this appears to be causing namespace resolution issues on some versions of gcc.

The tests (see C++ source in #54692) have multiple potential
optimizations/canonicalizations, but we should be consistent
since they are logically identical.

The bug number was typo'd when it was added for D86243.

The root of the buildvector can have only one use, otherwise it can be
treated only as a final element of the previous buildvector sequence.

isImpliedCondition() currently handles and/or on the LHS, but not
on the RHS, resulting in asymmetric behavior. This patch adds two
new implication rules:

 * LHS ==> (RHS1 || RHS2) if LHS ==> RHS1 or LHS ==> RHS2
 * LHS ==> !(RHS1 && RHS2) if LHS ==> !RHS1 or LHS ==> !RHS2

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

This patch adds initial support for a pointer diff based runtime check
scheme for vectorization. This scheme requires fewer computations and
checks than the existing full overlap checking, if it is applicable.

The main idea is to only check if source and sink of a dependency are
far enough apart so the accesses won't overlap in the vector loop. To do
so, it is sufficient to compute the difference and compare it to the
`VF * UF * AccessSize`. It is sufficient to check
`(Sink - Src) <u VF * UF * AccessSize` to rule out a backwards
dependence in the vector loop with the given VF and UF. If Src >=u Sink,
there is not dependence preventing vectorization, hence the overflow
should not matter and using the ULT should be sufficient.

Note that the initial version is restricted in multiple ways:

1. Pointers must only either be read or written, by a single
   instruction (this allows re-constructing source/sink for
   dependences with the available information)
 2. Source and sink pointers must be add-recs, with matching steps
 3. The step must be a constant.
 3. abs(step) == AccessSize.

Most of those restrictions can be relaxed in the future.

See https://github.com/llvm/llvm-project/issues/53590.

Reviewed By: dmgreen

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

Address the FIXME by marking the sendmsg instructions with
hasSideEffects.

Reviewed By: foad

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

On GFX10 VOP3 instructions can have a literal operand, so the conversion
from VOP3 MAD/FMA to VOP2 MADAK/MADMK/FMAAK/FMAMK will not happen in
SIFoldOperands. The only benefit of the VOP2 form is code size, so do it
in SIShrinkInstructions instead.

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

Add toKnownBits() method to mirror fromKnownBits(). We know the
top bits that are constant between min and max.

The return value for an empty range is chosen to be conservative.

Includes MachineCode layer support and tests, and MIR tests not requiring
CodeGen pass changes.
Includes a small change in SMInstructions.td to correct encoded bits.

Contributors:
Petar Avramovic <Petar.Avramovic@amd.com>
Dmitry Preobrazhensky <dmitry.preobrazhensky@amd.com>

Depends on D125316

Patch 6/N for upstreaming of AMDGPU gfx11 architecture.

Reviewed By: dp, Petar.Avramovic

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

`#pragma alloc_text` is a MSVC pragma that names the code section where functions should be placed. It only
applies to functions with C linkage.

https://docs.microsoft.com/en-us/cpp/preprocessor/alloc-text?view=msvc-170

Reviewed By: aaron.ballman

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

Reimplement the matching logic using Visitors instead of matchers.

Benchmarks from running the check over SemaCodeComplete.cpp
Before 0.20s, After 0.04s

Reviewed By: aaron.ballman

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

Reviewed By: craig.topper

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

This way, we could use it for LLVM_ENABLE_PROJECTS too if desired.

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

When legality check for vectoring reduction， hasVInstructions() check be unneeded. RISCV can only loop vectorization with hasVInstructions()

Reviewed By: kito-cheng, craig.topper

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

This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.

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

I noticed these two tests emit a warning about a missing
unhandled_exception.  That's irrelevant to what is being tested, but
is unnecessary noise.

Reviewed By: dblaikie

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

This should be a NFC cleanup. It removes a unnecessary loop to get the underlying
decl, and add an assertion.

The underlying decl of a using-shadow decl is always the original declaration
has been brought into the scope, clang never builds a nested using-shadow
decl (see Sema::BuildUsingShadowDecl).

Reviewed By: sammccall

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

The patch simplifies some of the patterns as below

(A | (B & C0)) | (B & C1) -> A | (B & C0|C1)
((B & C0) | A) | (B & C1) -> (B & C0|C1) | A

In some scenarios like byte reverse on half word, we can see this pattern multiple times and this conversion can optimize these patterns.

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

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

Only the most conservative of the DAG patterns matched, leaving GISel with "dmb
ish" everywhere which is inefficient.

Once we get into the if block we know the value of only_print_args.
Move some variables closer to point of use.

Depends on D125218

Reviewed By: JDevlieghere

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

Nowhere in lldb do we call this with a null pointer.
If we did, the first line of the function would fault anyway.

Reviewed By: JDevlieghere

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

Reviewed By: lattner, bzcheeseman

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

This change adds the constant splat versions of m_ICst() (by using
getBuildVectorConstantSplat()) and uses it in
matchOrShiftToFunnelShift(). The getBuildVectorConstantSplat() name is
shortened to getIConstantSplatVal() so that the *SExtVal() version would
have a more compact name.

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

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

Reported here: https://discourse.llvm.org/t/ir-alternatives-to-freeze-to-selectively-prevent-compiler-from-combining-shufflevectors/62521

The patch make users not need to know getNode with SDNodeFlags argument may not
pass its flags.

Reviewed By: craig.topper

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

Under some situations we can visit 64bit vector extract elements in
tryCombineFixedPointConvert, where an assert fires as they are expected
to have been converted to 128bit. Turn the assert into an if statement,
bailing out and letting the extract be handled first.

Also invert some ifs, using early exits to reduce indentation.

Fixes #55417

FunctionLoweringInfo::StatepointRelocationMaps map is used to pass GC pointer
lowering information from statepoint to gc.relocate  which may appear ini
different block.
D124444 introduced different lowering for local and non-local relocates.
Local relocates use SDValue and non-local relocates use value exported to VReg.
But I overlooked the fact that StatepointRelocationMap is indexed not by
GCRelocate instruction, but by derived pointer. This works incorrectly when
we have two relocates (one local and another non-local) of the same value,
because they need different relocation records.

This patch fixes the problem by recording relocation information per relocate
instruction, not per derived pointer. This way, each gc.relocate can be lowered
differently.

Reviewed By: skatkov

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

Clean up UnwrappedLineParser for RemoveBracesLLVM to avoid calling
mightFitOnOneLine() as much as possible.

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

I am working on support for forwarding parameter names in make_unique-like functions, first for inlay hints, later maybe for signature help.
For that to work generically, I'd like to parse all of these functions in the preamble. Not sure how this impacts performance on large codebases though.

Reviewed By: sammccall

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

This is based on https://reviews.llvm.org/D125168 which adds a
wrapper to allow use of opaque pointers from the C API.

I added an opaque pointer mode test to echo.ll, and to fix assertions
that forbid the use of mixed typed and opaque pointers that were
triggering in it I had to also add wrappers for setOpaquePointers()
and isOpaquePointer().

I also changed echo.ll to remove a bitcast i32* %x to i8*, because
passing it through llvm-as and llvm-dis was generating a
%0 = bitcast ptr %x to ptr, but when building that same bitcast in
echo.cpp it was getting elided by IRBuilderBase::CreateCast
(https://github.com/llvm/llvm-project/blob/08ac66124874d70dab63c731da0244f9e29ef168/llvm/include/llvm/IR/IRBuilder.h#L1998-L1999).

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

This is a mechanical change to avoid passing MRI and TII around
explicitly. NFC.

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

Make this an externally callable function for use in a future patch.

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

With this patch, we're able to parse smaller chunks of C++ code (statement,
declaration), rather than translation-unit.

The start symbol is listed in the grammar in a form of `_ :=
statement`, each start symbol has a dedicated state (`_ := • statement`).
We create and track all these separate states in the LRTable. When we
start parsing, we lookup the corresponding state to start the parser.

LR pasing table changes with this patch:
- number of states: 1467 -> 1471
- number of actions: 82891 -> 83578
- size of the table (bytes): 334248 -> 336996

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