This commit fixes a bug in the DICompositeType element ignore mode. It
seems that vectors require the presence of elements, as they otherwise
do not pass the verifier.

The implementation follows the ELF implementation.

This commit introduces a flag to allow skipping the potentially
recursive import of DICompositeType elements. This patch is essentially a
bandaid for the still broken recursive debug type import.

Some of our downstream inputs are produced by excessive usage of
template meta programming, and thus contain tens of thousands of types
that all participate in such recursions. Unfortunately, the series of
patches that introduces type support is not easily revertible due to
being around for a while now and Modular depending on it.

We can consider to revert this change once the type importer has show to
be very performant, but for now we are talking second vs hours to import
specific files.

OpenMP 5.2: Section 5.5.5: A procedure pointer must not appear in a
reduction clause.

Fixes #87915

This commit extends the data layout to support scalable vectors. For
scalable vectors, the `TypeSize`'s scalable field is set accordingly,
and the alignment information remains the same as for normal vectors.
This behavior is in sync with what LLVM's data layout queries are
producing.

Before this change, scalable vectors incorrectly returned the same size
as "normal" vectors.

Need to check that at least single bit is cleared for unsigned nodes
before reducing their size. Otherwise they might be treated as signed in
signed nodes.

Allow to fold or/and-and to BSL instuction for scalable vectors.

This reverts commit 74e07ab5.

It might be that Mask.getBitWidth() == Mask.countl_zero() (32 in my
case) and zero bitwidth2 causes the crash.

This patch fixes
https://github.com/llvm/llvm-project/pull/85592#issuecomment-2065865020.

I found this while fixing flag propagation in my
["vectorizer"](https://github.com/dtcxzyw/llvm-codegen-benchmark/blob/main/vectorize.cpp).

Solves SWDEV-449592

Restrict the types which are valid for EmitC operations. Use what is
currently supported by the emitter as restriction. Define a utility
functions for valid types, such that they can be used to restrict the
operations in table gen as well as being available for reuse in dialect
conversions.

Introduce new subclasses of VPWidenMemoryRecipe for VP
(vector-predicated) loads and stores to address multiple TODOs from
https://github.com/llvm/llvm-project/pull/76172

Note that the introduction of the new recipes also improves code-gen for
VP gather/scatters by removing the redundant header mask. With the new
approach, it is not sufficient to look at users of the widened canonical
IV to find all uses of the header mask.

In some cases, a widened IV is used instead of separately widening the
canonical IV. To handle that, first collect all VPValues representing header
masks (by looking at users of both the canonical IV and widened inductions
that are canonical) and then checking all users (recursively) of those header
masks.

Depends on https://github.com/llvm/llvm-project/pull/87411.

PR: https://github.com/llvm/llvm-project/pull/87816

These were added in https://reviews.llvm.org/D14208, which look like
they attempt to detect abs from xor+add+ashr. They do not appear to be
detecting the correct value for the src input though, which I think is
intended to be the sub(zext, zext) part of the pattern. We have pattens
from abs now, so the old invalid patterns can be removed.

Fixes #88784

Previously we use 'unsigned' as the type of ID in 'CreateDeserialized'.

And the type of `DeclID` in serialization is 'uint32_t', so there is
minor inconsistency.

Also more importantly, if we want to extend the type of DeclID from
uint32_t to uint64_t, we may be in trouble due to we forgot updating the
a lot of 'CreateDeserialized'.

So this patch tries to use semantical type 'DeclID' for
'*Decl::CreateDeserialized' to make sure it is tightly consistent.

For some reason, when I merged #89235, two lines were mis-formatted.

This patch corrects this; while I'm here, I'm also correcting other
existing formatting errors.

If there is no information about OpenCL version we are forced to
generate OpenCL 1.0 by default for the OpenCL environment to avoid
puzzling run-times with Unknown/0.0 version output. For a reference,
LLVM-SPIRV Translator avoids potential issues with run-times in a
similar manner.

This class no longer serves any purpose; see also the discussion here:
https://reviews.llvm.org/D155204#inline-1503204

A lot of existing tests in TransferTest.cpp check for the existence of
`RecordValue`s. Some of these checks are now simply redundant and have
been
removed. In other cases, tests were checking for the existence of a
`RecordValue` as a way of testing whether a record has been initialized.
I have
typically changed these test to instead check whether a field of the
record has
a value.

Before this change -gdwarf-5 on AIX will cause backend crash, because
some DWARF5 sections are not defined in XCOFF.
Explicitly statement -gdwarf-5 as unsupported in frontend on AIX.

Similarly to #87965, delete check lines which do not have corresponding
FileCheck run lines in tiny-model-pic.ll (while having them tested in
tiny-model-static.ll).

when unset -fopenmp tries to find the library itself and in some
configurations this test fails

fix for #88545 8f07a67f

Commit 5f87957f (pull-requst #80515) corrected some codegen
problems related to _BitInt types being used as shift exponents. But it
did not fix it properly for the special case when the shift count
operand is a signed _BitInt.

The basic problem is the same as the one solved for unsigned _BitInt. As
we use an unsigned comparison to see if the shift exponent is
out-of-bounds, then we need to find an unsigned maximum allowed shift
amount to use in the check. Normally the shift amount is limited by
bitwidth of the LHS of the shift. However, when the RHS type is small in
relation to the LHS then we need to use a value that fits inside the
bitwidth of the RHS instead.

The earlier fix simply used the unsigned maximum when deterining the max
shift amount based on the RHS type. It did however not take into
consideration that the RHS type could have a signed representation. In
such situations we need to use the signed maximum instead. Otherwise we
do not recognize a negative shift exponent as UB.

Reverts llvm/llvm-project#89312 as it breaks all flang buildbots

This transform is only valid if the (modular) shift amount is not
zero.

Proof: https://alive2.llvm.org/ce/z/WBxn-x

Fixes https://github.com/llvm/llvm-project/issues/89338.

Without this patch, a lot of details about the deserilization of the
MemProf data are exposed in IndexedInstrProfReader -- four
MemProf-related variables in IndexedInstrProfReader plus 90+ lines of
deserilization code within IndexedInstrProfReader::readHeader.

This patch encapsulates them into a separate class, exposing only
three methods, namely the default constructor, deserialize, and
getMemProfRecord.

This patch fixes

  clang/lib/Sema/SemaStmtAttr.cpp:114:18: error: unused variable 'R'
  [-Werror,-Wunused-variable]

Since `vcreate` doesn't support overload, we can remove it.

[Clang] Allow the value of unroll count to be zero  in `#pragma GCC unroll` and `#pragma unroll` (#88666)

Fixes https://github.com/llvm/llvm-project/issues/88624

GCC allows the value of loop unroll count to be zero, and the values of
0 and 1 block any unrolling of the loop. This PR aims to make clang
keeps the same behavior with GCC.
https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html



---------

Signed-off-by: yronglin <yronglin777@gmail.com>

If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.

Let's also place libclang_rt into lib/<normalized_triple>.
`libcxx/utils/ci/run-buildbot` is also updated to use
`armv7m-none-unknown-eabi` as normalized triple instead of
current `armv7m-none-eabi`.

ChangeLog of this PR:
This patch has been applied and revert twice:
1. The first try is https://github.com/llvm/llvm-project/pull/88407, and
then it is found that it causes some CI failures.
    https://lab.llvm.org/buildbot/#/builders/98/builds/36366
It is then resolved by another commit:
https://github.com/llvm/llvm-project/commit/1693009679313282afbed38778dd3fad62641e1b

    https://lab.llvm.org/buildbot/#/builders/77/builds/36372
It is caused that `COMPILER_RT_DEFAULT_TARGET_TRIPLE` is overwrite
without taking care about `CACHE`.

2. The second try https://github.com/llvm/llvm-project/pull/88835,
     resolves https://lab.llvm.org/buildbot/#/builders/77/builds/36372
     and in fact only one `execute_process` is needed.

Then we find some other CI failures. 
https://github.com/mstorsjo/llvm-mingw/actions/runs/8730621159

https://buildkite.com/llvm-project/libcxx-ci/builds/34897#018eec06-612c-47f1-9931-d3bd88bf7ced

It is due to misunderstanding `-print-effective-triple`: which will
output `thumbv7-w64-windows-gnu` for `armv7-w64-windows-gnu` or some
other thumb-enabled arm triples.
In fact we should use `-print-target-triple`.

For armv7m-picolibc, `armv7m-none-eabi` is hardcoded in
libcxx/utils/ci/run-buildbot, while in fact `armv7m-none-unknown-eabi`
is the real normalized triple.

APX spec: https://cdrdv2.intel.com/v1/dl/getContent/784266
Change happended in version 4.0.
Removed instructions' Opcodes:
AESDEC128KL
AESDEC256KL
AESDECWIDE128KL
AESDECWIDE256KL
AESENC128KL
AESENC256KL
AESENCWIDE128KL
AESENCWIDE256KL
ENCODEKEY128
ENCODEKEY256
SHA1MSG1
SHA1MSG2
SHA1NEXTE
SHA1RNDS4
SHA256MSG1
SHA256MSG2
SHA256RNDS2

InstCombine may invert branch condition and profile metadata. Branch
probability analysis should be updated in this case.

Close https://github.com/llvm/llvm-project/issues/85122

As the title suggested, it looks pretty sensible.

This allows vector splats containing poison for matchers using
api_pred_ty, making the behavior consistent with cst_pred_ty. In other
words, previously `m_NonNegative()` allowed splats with poison, while
`m_NonNegative(C)` did not. Now both allow them.

The affected matchers are m_MaxSignedValue, m_Negative, m_NonNegative,
m_StrictlyPositive, m_NonPositive, m_Power2, m_Power2OrZero,
m_NegatedPower2, m_NegatedPower2OrZero, m_LowBitMask and
m_LowBitMaskOrZero when passing in APInt.

I briefly went through the uses of these matchers and didn't spot any
places where allowing poison would be obviously wrong (I initially
thought foldSelectICmpAndBinOp is problematic, but because it does not
reuse the original constants, it's fine).

A problem here is that, despite these matchers appearing in a decent
number of places, we have very little pre-existing test coverage for
these folds with poison vectors, so we don't benefit from alive2
verification.

Only unique `OpaqueValueExpr`s should be handled in the mapping builder,
as
[discussed](https://github.com/llvm/llvm-project/pull/85837#discussion_r1542056451)
in #85837. However, `getCond()` returns non-unique `OpaqueValueExpr` for
`BinaryConditionalOperator` (because it is also used as the "true"
branch expression). Use `getCommon()` instead so as to bypass the
`OpaqueValueExpr`.

This adds proper support for calling intrinsics without mangling suffix
when parsing textual IR. This already worked (mostly by accident) when
only a single mangling suffix was in use.

This patch extends support to the case where the intrinsic is used with
multiple signatures, and as such multiple different intrinsic
declarations have to be inserted. The final IR will have intrinsics with
mangling suffix as usual.

Motivated by the discussion at:
https://discourse.llvm.org/t/recent-improvements-to-the-ir-parser/77366

Now that we don't accept undef splat in PatternMatch, we can remove some
uses of replaceUndefsWith(). I believe in all these cases only poison
splats are possible now, in which case no replacement is necessary.