If a function happens to:

- call setjmp
- do a 16-byte stack allocation
- call a function that sets up a stack frame and longjmp's back

The stack pointer that is restores by setjmp will no longer point to a valid
back chain. According to the ABI, stack accesses in such a function are to be
frame pointer based - so it is an error (quite obviously) to restore the stack
from the back chain.
We already restore the stack from the frame pointer when there are calls to
fast_cc functions. We just need to also do that when there are calls to setjmp.
This patch simply does that.

This was pointed out by the Julia team.

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

This commit splits SPIR-V's serialization and deserialization code
into separate libraries. The motiviation being that the serializer
is used more often the deserializer and therefore lumping them
together unnecessarily increases binary size for the most common
case.

This commit also moves these libraries into the Target/ directory
to follow MLIR convention.

Reviewed By: antiagainst

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

The import of a typedefs with an attribute uses clang::Decl::setAttrs().
But that needs the ASTContext which we can get only from the
TranslationUnitDecl. But we can get the TUDecl only thourgh the
DeclContext, which is not set by the time of the setAttrs call.

Fix: import the attributes only after the DC is surely imported.
Btw, having the attribute import initiated from GetImportedOrCreateDecl was
fundamentally flawed. Now that is implicitly fixed.

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

[SimplifyCFG] FoldBranchToCommonDest(): temporairly put back restrictions on liveout uses of bonus instructions (PR48450)

Even though d3820514 was mostly a correct
fix for the external non-PHI users, it's not a *generally* correct fix,
because the 'placeholder' values in those trivial PHI's we create
shouldn't be *always* 'undef', but the PHI itself for the backedges,
else we end up with wrong value, as the `@pr48450_2` test shows.

But we can't just do that, because we can't check that the PHI
can be it's own incoming value when coming from certain predecessor,
because we don't have a dominator tree.

So until we can address this correctness problem properly,
ensure that we don't perform the transformation
if there are such problematic external uses.

Making dominator tree available there is going to be involved,
since `-simplifycfg` pass currently does not preserve/update domtree...

Makes it easier to use it elsewhere

- std::reference_wrapper
- std::function
- std::mem_fn

While I'm here, remove _VSTD:: qualification from calls to `declval`
because it takes no arguments and thus isn't susceptible to ADL.

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

Everywhere, normalize the whitespace to `::new (EXPR) T`.
Everywhere, normalize the spelling of the cast to `(void*)EXPR`.

Without the cast to `(void*)`, the expression triggers ADL on GCC.
(I think this is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249)
Even if it doesn't trigger ADL, it still seems incorrect to use any argument
that's not exactly `(void*)` because that opens the possibility of overload
resolution picking a user-defined overload of `operator new`, which would be
wrong.

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

clang-scan-deps contains some command line parsing and modifications.
This patch adds support for clang-cl command options.

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

D82227 has added a proper check to limit PHI vectorization to the
maximum vector register size. That unfortunately resulted in at
least a couple of regressions on SystemZ and x86.

This change reverts PHI handling from D82227 and replaces it with
a more general check in SLPVectorizerPass::tryToVectorizeList().
Moved to tryToVectorizeList() it allows to restart vectorization
if initial chunk fails.

However, this function is more general and handles not only PHI
but everything which SLP handles. If vectorization factor would
be limited to maximum vector register size it would limit much
more vectorization than before leading to further regressions.
Therefore a new TTI callback getMaximumVF() is added with the
default 0 to preserve current behavior and limit nothing. Then
targets can decide what is better for them.

The callback gets ElementSize just like a similar getMinimumVF()
function and the main opcode of the chain. The latter is to avoid
regressions at least on the AMDGPU. We can have loads and stores
up to 128 bit wide, and <2 x 16> bit vector math on some
subtargets, where the rest shall not be vectorized. I.e. we need
to differentiate based on the element size and operation itself.

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

This reverts commit 03ebe1937192c247c4a7b8ec19dde2cf9845c914.

It's still breaking bots, e.g. http://green.lab.llvm.org/green/job/clang-stage1-RA/17027/console although it doesn't change any actual code.
The compile errors don't make much sense either. Revert for now.

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

We have this subtarget feature so it makes sense to use it here. This is
NFC because it's always defined by default on GFX8+.

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

Add andm, orm, xorm, eqvm, nndm, negm, pcvm, lzvm, and tovm intrinsic
instructions, a few pseudo instructions to expand logical intrinsic
using VM512, a mechnism to expand such pseudo instructions, and
regression tests.  Also, assign vector mask types and vector mask
register classes correctly.  This is required to use VM512 registers
as function arguments.

Reviewed By: simoll

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

Prep work for undef/zero 'upper elements' handling as proposed in D92645.

That's a follow-up patch after D92769.

Reviewed By: ldionne, #libc

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

Correct addRegisterClass calls for vector mask registers.

Reviewed By: simoll

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

This bug hasn't affected us yet as our usage is too basic, i.e. we don't
rely on the defaults provided by `SetDefaultFortranOpts` just yet. This
will change shortly.

Summary:

fixed a  Fixed "comparison of unsigned expression >= 0 is always true" gcc warnings.
http://lab.llvm.org:8011/#/builders/5/builds/2407/steps/2/logs/stdio

the error caused by patch https://reviews.llvm.org/D92398

Use SCEV to salvage additional @llvm.dbg.value that have turned into
referencing undef after transformation (and traditional
salvageDebugInfo).  Before rewrite (but after introduction of new
induction variables) use SCEV to compute an equivalent set of values for
each @llvm.dbg.value in the loop body (among the loop header PHI-nodes).
After rewrite (and dead PHI elimination) update those @llvm.dbg.value
now referencing undef by picking a remaining value from its equivalence
set.  Allow match with offset by inserting compensation code in the
DIExpression.

Fixes : PR38815

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

Otherwise they come out in random (inode?) order.

Also `chmod +x` the generator, and re-run it. Somehow on Marek's
machine it produced \r\n line endings?! Open all files with
`newline='\n'` so that (if the Python3 docs are correct)
that won't happen again.

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

This type has been unused since commit 5b4cc84b.

aa772fc8 (D92530) has landed fixing Apple builds.
Previous quick-fix d9697c2e (D93198) included in this commit.

Invoking the preprocessor ourselves is fragile and would require us to replicate CMake's handling of definitions, compiler flags, etc for proper compatibility.
In my toolchain builds this notably resulted in a bunch of warnings from unused flags as my CMAKE_C_FLAGS includes CPU-specific optimization options.
Notably this part was already duplicating the logic for VISIBILITY_HIDDEN define.

Instead, symlink the files and set the proper set of defines on each.
This should also be faster as we avoid invoking the compiler multiple times.

Fixes https://llvm.org/PR48494

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

Reviewed By: ilinpv

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

This patch updates VPWidenMemoryInstructionRecipe to use VPDef
to manage the value it produces instead of inheriting from VPValue.

Reviewed By: gilr

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

Single dash for these options is not recognised.

Changes found by running this on the --help output
and the user guide:
grep -e ' -[a-zA-Z]\{2,\}'

The user guide was updated in https://reviews.llvm.org/D92305
so no change there.

Reviewed By: jhenderson, MaskRay

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

Revert "Consider reference, pointer, and pointer-to-member TemplateArguments to be different if they have different types."

This reverts commit 05cdf4ac. It breaks stage-2
compilation of LLVM, see https://reviews.llvm.org/D91488#2451534

Vector element size could be different for different store chains.
This patch prevents wrong computation of maximum number of elements
for that case.

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

dyn_cast<> can return null if the cast fails, resulting in null dereferences and static analyzer warnings. We should use cast<> instead.

Changes in this patch:
-  Minor changes to the LowerVECREDUCE_SEQ_FADD function added by @cameron.mcinally
   to also work for scalable types
- Added TableGen patterns for FP reductions with unpacked types (nxv2f16, nxv4f16 & nxv2f32)
- Asserts added to expandFMINNUM_FMAXNUM & expandVecReduceSeq for scalable types

Reviewed By: cameron.mcinally

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

A vpt block that just contains either VPST;VCTP or VPT;VCTP, once the
VCTP is removed will become invalid. This fixed the first by removing
the now empty block and bails out for the second, as we have no simple
way of converting a VPT to a VCMP.

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

These parameters set a default value of 0, so I believe they
should include a 0 suffix. This allows for versions which do not
set a default value in future.

Reviewed By: foad

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

This is unused and the selection function does not exist.

Reviewed By: foad

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

It hasn't been necessary since commit 4d4ed0e2 (D43278).

Reviewed By: dberris

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

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

- Allows lds allocations
- Writes resource usage into COMPUTE_PGM_RSRC1 registers in PAL metadata

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