For some reason the expected ignore_format.txt changed. This patch fixes it in trunk, but the problem is being investigated.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits, arichardson

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

Reviewed By: ftynse

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

Fixes a mistake in the lowering of memref.alloca to llvm.alloca, as llvm.alloca uses the number of elements to allocate in the stack and not the size in bytes.

Reference:
LLVM IR: https://llvm.org/docs/LangRef.html#alloca-instruction
LLVM MLIR: https://mlir.llvm.org/docs/Dialects/LLVM/#llvmalloca-mlirllvmallocaop

Reviewed By: ftynse

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

[clang][AST] TextNodeDumper should not evaluate the initializer of constexpr variable declaration when it has a dependent type

`TextNodeDumper` enabed through `-ast-dump` flag should not evlauate the initializer when it visits a constexpr `VarDecl` node if it has a dependent type.

I found a crashing case fixed by this change and added it as a test case.
`template <typename T> constexpr T call_init(0);`
Link: https://godbolt.org/z/3bG9Pjj5E

This is a fix for the regression caused by D146358

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

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

This reverts commit 8dec295a.

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

This assert should have the same set of vector types as the binary
and ternary case (although this assert is kind of pointless, the code
should work for any vector type as-is).

Fixes part of issue #32650.

If the second argument of V_SET_INACTIVE is undef/poison,
SIWholeQuadMode lowered it to a COPY from the first argument, but that
caused invalid MIR if the first argument was an immediate rather than a
register.

Fix this by lowering to a V_MOV instruction instead of a COPY.

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

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

Currently there is no documentation for these flags, users might find it
confusing to know which values are permitted. This change simply adds
documentation to suggest using `-mcpu=help` to list the availible target
names.

Reviewed By: aaron.ballman

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

Output on Windows is "llvm-profdata.exe"

LLVM fails to build in some environments with EXPENSIVE_CHECKS
due to the use of uint64_t without including cstdint.

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

Given two Store instructions with equivalent pointer operands,
they could be merged into their common successor basic block if
the value operand of one is bitcasted to match the type of the
other.

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

The convert intrinsics can be used to implement existing operations on svcount_t
when the actual bits/content of the predicate register doesn't matter (such
as PSEL, which copies the full contents of the first source register to the
destination register).

Reviewed By: CarolineConcatto, david-arm

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

All the bits of the first operand are copied to the destination register,
if the tested bit (in the second source operand) is active. This means we
copy over all vscale x 16 x i1's of the first operand. There is no need to
overload that type.

Reviewed By: david-arm

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

These intrinsics are used to implement multi-vector load/store intrinsics that loads
or stores a tuple of 2 or 4 values, based on a predicate-as-counter operand, e.g.

  __attribute__((arm_streaming))
  svuint8x2_t svld1[_u8]_x2(svcount_t png, const uint8_t *rn);

  __attribute__((arm_streaming))
  void svst1[_u8_x2](svcount_t png, uint8_t *rn, svuint8x2_t zt);

As described in https://github.com/ARM-software/acle/pull/217

Reviewed By: CarolineConcatto

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

These intrinsics are used to implement the sel intrinsics that selects
a tuple of 2 or 4 values based on a predicate-as-counter operand, e.g.

  __attribute__((arm_streaming))
  svuint8x2_t svsel[_u8_x2](svcount_t png, svuint8x2_t zn, svuint8x2_t zm);

  __attribute__((arm_streaming))
  svuint8x4_t svsel[_u8_x4](svcount_t png, svuint8x4_t zn, svuint8x4_t zm);

As described in https://github.com/ARM-software/acle/pull/217

Reviewed By: CarolineConcatto

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

Store the end iterator on the VisitStack, instead of recomputing
it every time, as doing so is not free.

The `llvm-profdata --version` output now looks like:

  llvm-profdata
  LLVM (http://llvm.org/):
    LLVM version 17.0.0git
    Optimized build with assertions.

This makes llvm-profdata more consistent with other tools.

Reviewed By: simon_tatham

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

Missed a hunk in a6e2b1ee.

This means the test properly checks that RISCVISAInfo includes the
implication for the F extension (directly, or indirectly through
zve32f).

Due to missing check on union, there was a null expression
added to init list that caused crash later.

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

Reviewed By: aaron.ballman, shafik

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

This fixes assertion crash in https://github.com/llvm/llvm-project/issues/62380.

In the beginning of ScalarEvolution::getBackedgeTakenInfo
we make sure that BackedgeTakenCounts contains an entry
for the given loop.
Then we call computeBackedgeTakenCount which computes the result,
and in the end we insert it in the map like so:

  return BackedgeTakenCounts.find(L)->second = std::move(Result);

So we expect that the entry for L still exists in the cache.
However, it can get deleted. When it has computed the result,
getBackedgeTakenInfo clears all the cached SCEVs that use the AddRecs in the loop.

In the crashing example, getBackedgeTakenInfo first gets called on an inner loop,
and during this call it gets called again on its parent loop.
This recursion happens after the call to computeBackedgeTakenCount.
And it happens so that some SCEV from the BTI of the child loop uses
an AddRec of the parent loop. So when we successfully compute BTI
for the parent loop, we erase already computed result for the child one.

The recursion happens in some debug only code that
updates statistics. The algorithm itself is non-recursive.
Namely the recursive call happens in BackedgeTakenInfo::getExact function
and its return value is only used to compare it against SCEVCouldNotCompute.

As suggested by nikic I replaced the NumTripCountsComputed and NumTripCountsNotComputed
with NumExitCountsComputed and NumExitCountsNotComputed respectively.
They are updated during computations made for single exits. It relieves us of the need
to compute exact exit count for the loop just to update the named
statistic and thus the recursion cannot happen anymore.

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

For a GEP in a pointer chain, if:
1) a pointer chain is unit-strided
2) the base pointer wasn't folded and is sitting in a register somewhere
3) the distance between the GEP and the base pointer is small enough and
   can be folded into the addressing mode of the using load/store

Then we can exclude that GEP from the total cost of the pointer chain,
as it will likely be folded away.

In order to check if 3) holds, we need to know the type of memory access
being made by the users of the pointer chain. For that, we need to pass
along a new argument to getPointersChainCost. (Using the source pointer
type of the GEP isn't accurate, see https://reviews.llvm.org/D149889 for
more details).

Also note that 2) is currently an assumption, and could be modelled more
accurately.

This prevents some unprofitable cases from being SLP vectorized on
RISC-V by making the scalar costs cheaper and closer to the actual
codegen.

For now the getPointersChainCost hook is duplicated for RISC-V to prevent
disturbing other targets, but could be merged back in and shared with
other targets in a following patch.

Reviewed By: ABataev

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

Add support for representing array constants of any rank with MLIR
dense attribute. This greatly improves compile time and memory
usage of programs with large array constants. We still support only
arrays of a few basic types, such as integer, real and logic.

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

Reviewed By: jeanPerier

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

Revert "Revert "[Flang][OpenMP][MLIR] Add declare target attribute set and interface for the OpenMP dialect""

This reverts commit aa6b47cd.

And adds a fix (adding missing libraries
to CMakeLists.txt for the OpenMPDialect)
that allows failing builds to succeed.

The op bufferizes similarly to tensor.generate: it is lowered to a linalg.map, which may then lower to a loop nest that fills the buffer.

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

The crash was due to unconditionally calling
`Block.succ_begin()->getReachableBlock()->hasNoReturnElement()`, but
`getReachableBlock()` can return null now that we have turned
`PruneTriviallyFalseEdges` on.

This patch adds two tests that crash without the fix.

Reviewed By: ymandel

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

Arrays and their element types are identically qualified as of C2x,
and we support that behavior as far back as C89.

As a drive-by, this adds the paper number for designated initializers
so that all the WG14 features can be uniquely identified despite the
lack of a feature testing macro.

This operation is not marked pure because it needs to survive DCE, but
is otherwise safe to inline.

Reviewed By: Dinistro

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

We can not yet generate new aliasing metadata based on these arguments
because their global nature does not allow parallel inlining, but since
this is not necessary for correctness, we allow inlining functions that
have arguments with the noalias attribute for now.

Reviewed By: gysit

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

This fixed missing import of lldbsuite.test.decorators in TestInterruptBacktrace.py.

We naively broke all incoming values, assuming they'd be unique.
However it's not illegal to have multiple occurences of, e.g. `[BB0, V0]`
in a PHI node. What's illegal though is having the same basic block
multiple times but with different values, and it's exactly what the
transform caused. This broke in some rare applications where the pattern
arised.

Now we cache the `BasicBlock, Value` pairs we're breaking so we can reuse the values and preserve this invariant.

Solves SWDEV-399460

Reviewed By: #amdgpu, rovka

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

For the cover letter of this patch-set, please checkout D146872.

Depends on D147916.

This is the 11th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Only vset for tuple type of NF=2, EEW=32, LMUL=1 is
defined now.

Reviewed By: craig.topper

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

For the cover letter of this patch-set, please checkout D146872.

Depends on D147915.

This is the 10th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Only vget for tuple type of NF=2, EEW=32, LMUL=1 is
defined now.

Reviewed By: craig.topper

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

For the cover letter of this patch-set, please checkout D146872.

Depends on D147914.

This is the 9th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple indexed segment store is
not removed, and only signed integer indexed segment store of NF=2,
EEW=32 is defined here.

Reviewed By: craig.topper

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

For the cover letter of this patch-set, please checkout D146872.

Depends on D147913.

This is the 8th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple indexed segment load is
not removed, and only signed integer indexed segment load of NF=2,
EEW=32 is defined here.

Reviewed By: craig.topper

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