Fixed two test cases that relied on Asserts, and added a fallthrough
annotation to the switch case.

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

This limitation was discovered thanks to some regression in D127115 .

Reviewed By: RKSimon

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

Ensure we test different vector element sizes

vector-bo-select.ll should only be used for binop identity select tests

These methods can be called with an O0 level nowadays.

Reviewed By: gribozavr2

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

In the non-ThinLTO pipeline this was directly before PipelineStartEP,
in the ThinLTO pipeline it was directly after. I don't think the
specific position matters here, just make sure it's the same for
both pipelines.

buildModuleSimplificationPipeline() is not used for O0.

The math libraries have a lot of code that performs
manual sign bit operations by bitcasting doubles to int2
and doing bithacking on them. This is a bad canonical form
we should rewrite to use high level sign operations directly
on double. To avoid codegen regressions, we need to do a better
job moving fnegs to operate only on the high 32-bits.

This is only halfway to fixing the real case.

Added multiuse checks for v8i16 and v8f32 cases

Ops from the Math dialect use fastmath attributes defined in Arith.
Therefore Math dialect must declare a dependency on Arith for proper
construction and parsing.

Reviewed By: tpopp

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

Avoid divergence b/w different kinds of hoisting with reassociation.
Make them all collect general stat NumHoisted and also specific stats
for each particular transform.

Reviewed By: MatzeB

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

They all are now handled by hoistArithmetics, and only it should be
forwarded.

Should not optimize here because no-overflow is not proved.

In this case the source GEP might not be hoisted even though it
has invariant operands. For now just bail out, but we might need
additional checks for AllowSpeculation in these special-case
reassociation folds.

Depends on D145791

Storing instruction bytes directly in a SmallVector instead of a
raw_ostream yields better encoding performance (in some applications,
the improvment is ~1% of the complete back-end time).

Reviewed By: MaskRay, Amir

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

The type of a function is nowadays just an opaque pointer, which is not
helpful when analyzing FastISel misses. Instead print the actual
function type of the function.

Reviewed By: efriedma

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

This used to say:
For example, clang --target=aarch64-unknown-linux-gui -mcpu=cortex-a35

Which works but I think it was meant to be `-gnu` not `-gui`. From my
AArch64 Linux build:
```
$ ./bin/clang --version
clang version 17.0.0 <...>
Target: aarch64-unknown-linux-gnu
```

Originally added in af857b93.

This reverts commit d0027e0b.

Need to look at 2 test failures.

The GFX11 NGG Streamout Instructions perform atomic operations on
dedicated registers. At the moment, they lack machine memory operands,
which causes the si-memory-legalizer pass to treat them conservatively
and introduce several unnecessary waits and cache invalidations.

This patch introduces a new address space to represent these special
registers and teaches instruction selection to add memory operands with
this new address space to DS_ADD/SUB_GS_REG_RTN.

Since this address space is meant to be compiler-internal, we move it
up a bit from the other address spaces and give it the number 128.
According to the LLVM Language Reference, address space numbers can go
all the way up to 2^24, but I'm not sure how well this is supported in
practice [1], so using a smaller number seems safer.

[1] https://github.com/llvm/llvm-project/blob/0107513fe79da7670e37c29c0862794a2213a89c/llvm/utils/TableGen/IntrinsicEmitter.cpp#L401

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

When we encounter an `else`, `catch`, or `catch_all`, we currently just
push the structure `NestingType` and don't preserve the original `if`
and `try`'s signature. So after we pass `else`/`catch`/`catch_all`, we
can't check if the values on stack have the correct types when we
encounter `end_if` or `end_try`. This CL fixes the issue, and modifies
the existing test to be correct (some of them had `try` without
`catch`).

Reviewed By: dschuff

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

We disable type check in unreachable code, but when the unreachable code
is enclosed within a block-like structure, the block as a whole has a
valid type and we should continue type checking after the block. But it
looks we currently only do that for blocks and not other block-like
structures (`loop`s, `try`s, and `if`s). Also unreachable code within
`if`'s true body shouldn't disable type checking in `else` body, and
that in `try` body shouldn't disable type checking in `catch/catch_all`
body.

This also causes the values/types on the stack to be correctly checked
when encounterint `catch`, `catch_all`, and `delegate`.

Reviewed By: dschuff

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

The current code is
```
      ExpectBlockType = false;
      TC.setLastSig(*Signature.get());
      if (ExpectBlockType)
        NestingStack.back().Sig = *Signature.get();
```

Because of the first line, the third line's `if (ExpectBlockType)` is
always false and we don't get to update `NestingStack.back().Sig`. This
results in not correctly erroring out when the types of remaining values
on the stack do not match the block type if the block type is written in
the form of a function type. We should set `ExpectBlockType` to false
after the `if`.

Reviewed By: sbc100

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

This lowers the cost for FADD, FSUB, and FNEG. The motivation is to avoid
over-eager SLP vectorisation, that makes it look like SLP vectorisation is
profitable but results in significant slow downs. Lowering the cost for scalar
FADD/FSUB costs helps the profitability decision to favour the scalar
version where vectorisation isn't beneficial.

Lowering the cost for these floating point operations makes sense because a lot
of other instructions including many shuffles have only a cost of 1; these
FADD/FSUB/FNEG instructions should not be twice the cost.

Performance results show a 7% improvement for Imagick from SPEC FP 2017, a
small improvement in Blender, and unchanged results for the other apps in SPEC.
RAJAPerf is neutral and mostly shows no changes.

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

Reassociate gep (gep ptr, idx1), idx2 to gep (gep ptr, idx2), idx1
if this would make the inner GEP loop invariant and thus hoistable.

This is intended to replace an InstCombine fold that does this (in
https://github.com/llvm/llvm-project/blob/04f61fb73dc6a994ab267d431f2fdaedc67430ff/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2006).
The problem with the InstCombine fold is that LoopInfo is an optional
dependency, so it is not performed reliably.

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

When converting this test to opaque pointers, we get a register
move between the call and the inline asm. However, the test
comment specifically says that there should be nothing between them.

As far as I can tell, this is fine, both in that the inline asm
doesn't use the relevant registers, but also more generally
because the inline asm doesn't declare any clobbers, so really
LLVM can do whatever, side effects or not. The test was added
by 618ce3e8 with only a reference
to Apple's internal issue tracker.

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

[[https://wg21.link/p1787 | P1787]]: CWG1822 is resolved by specifying that the body of a lambda remains in the surrounding (function parameter) scope.
Wording: A parameter-declaration-clause P introduces a function parameter scope that includes P. <...> If P is associated with a lambda-declarator, its scope extends to the end of the compound-statement in the lambda-expression. ([basic.scope.param])

Reviewed By: #clang-language-wg, shafik

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

This change is made to enable conversion of a masked icmp splat vector
containing poison/undef to an equality expression.

llvm::decomposeBitTestICmp Alive2 correctness examples using splat/masking vectors:

    SLT <    https://alive2.llvm.org/ce/z/pPTTHh
    SLE <=   https://alive2.llvm.org/ce/z/qQhAmU
    SGT >    https://alive2.llvm.org/ce/z/koFHzF
    SGE >=   https://alive2.llvm.org/ce/z/3SNz2S
    ULT <u   https://alive2.llvm.org/ce/z/W8ktzQ
    ULE <=u  https://alive2.llvm.org/ce/z/G5SdUY
    UGT >u   https://alive2.llvm.org/ce/z/WFwYxq
    UGE >=u  https://alive2.llvm.org/ce/z/DzJszP

Tests have been verified using Alive2:

    icmp-logical.ll: @nomask_splat_and_B_allones       https://alive2.llvm.org/ce/z/zmJwQU
    icmp-logical.ll: @nomask_splat_and_B_mixed         https://alive2.llvm.org/ce/z/ktzgzd
    signed-truncation-check.ll: @positive_vec_undef0   https://alive2.llvm.org/ce/z/-sTRLD

Differential Revision: https:/...

Add tests to verifying future support for splat vectors containing poison/undef in llvm::decomposeBitTestICmp.

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