The LDR and STR instructions must have the same value for imm4(second operand)
and offset(fourth operand).
The disassembly guarantees that happens, but the Asm parser was not checking that.
This patch fixes that by checking if the second operand and fourth operand are
immediate and have the same value.

Reviewed By: david-arm

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

Due to not resetting that, clang still thinks that it is in immediate
function context even if it already entered non-consteval function.
This caused consteval functions reaching codegen in some cases.

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

Reviewed By: cor3ntin, aaron.ballman

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

FCMP may use ISD::SETNE when nnan, we don't want to end up with cases where we mismatch signed zeros etc.

Thanks to @pengfei for the test case from D147688

This reverts commit efd34ba6.

Reapplies 8ff48326. Missed a failing test. Needed to just
update test checks.

[SVE][InstCombine] Don't convert calls to fp binop intrinsics to instructions when strictfp is required.

There's no support to lower scalable vector constrained operations for SVE
and thus without this change we'll crash during code generation.

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

When optimizing vmv.s.x/vmv.v.x's of scalar loads, if VL is known to be
1 then we don't need to perform a stride of x0, and can just do a
regular load.

Reviewed By: craig.topper

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

Performance counters may be unavailable due to various reasons (such as
access restriction via sysctl properties or the CPU model being unknown
to libpfm). On the other hand, for debugging llvm-exegesis itself it is
still useful to be able to run generated code snippets to ensure that
the snippet does not crash at run time.

The --use-dummy-perf-counters command line option makes llvm-exegesis
behave just as usual except for using fake event counts instead of asking
the kernel for actual values.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

This broke build bots, e.g:
https://lab.llvm.org/buildbot/#/builders/139/builds/38697

If the HLSL entry function had a shader attribute that conflicted
with the pipeline stage specified in the target triple, Clang
would emit:

   error: (null) attribute parameters do not match the previous declaration
   conflicting attribute is here

(where the second line doesn't reference an attribute).

This was because the code constructed a dummy attribute that had
only a source location, but no kind or syntax.

Noticed while doing some changes to the attribute handling.

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

DAG::SplitVector only works with vectors with even numbers of elements, when splitting vectors with large (illegal) element widths, we are likely to split down to <1 x iXXX>.

In such cases, pre-bitcast to a <X x i64> type to ensure splitting will always succeed.

Thanks to @alexfh for identifying this.

Re-write the code to avoid iteration over users of
constants and global values.

Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D147450

If we're inserting a fixed length subvector into a fixed length vector,
then we can use a tail agnostic policy as long as we're inserting up to
or past the end of the main vector.
I.e., because we're overwriting all of the main vector's tail elements,
and we don't care what the elements after that are.
As noted by Philip in https://reviews.llvm.org/D146711#4220341

Reviewed By: craig.topper

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

I personally find it handy to be able to run the check-llvm-codegen-riscv-rvv target to test anything that involves vector codegen, so this patch moves some more vector-based test cases into that directory to increase its coverage.

Reviewed By: craig.topper

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

Test variations where catch/filter catch all exceptions.

In getInstructionCost if we know a zext/sext is going to be shrunk
we should only be changing the destination type, and leave the
source type unchanged. For example, we may change a zext from

  zext <16 x i8> %a to <16 x i32>

to

  zext <16 x i8> %a to <16 x i16>

However, we were previously calculating the cost for doing

  zext <16 x i16> %a to <16 x i16>

which is incorrect.

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

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

For PR61945.

We use this quite a bit, so add some convenience API for it.

Instead of the version that uses a switch statement to figure this out.

The target_is_msvc variable in lit.cfg.py matches a similar pattern
used in the asan lit.cfg.py.

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

This fixes building the tests so that the tests can start
executing (even if there still are lots of failures).

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

I don't see why we can't have this target when built as a project alongside
llvm; especially in such build configs, it's useful to have one single target
for running all tests (in standalone builds, check-all does the same too),

Keep the creation of the check-all target only for standalone builds.

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

This matches how it is done for libcxx and libcxxabi.

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

In most configs, stderr is line buffered by default, but in some
cases on Windows (running in git bash, or running in Wine) stderr
can end up fully buffered.

See 2ec75a08 for a similar change
for the output from lit itself.

This has no effect on libunwind when the log messages aren't enabled
via the environment variables.

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

This typo (unw_step instead of unw_get_proc_info) has been around since
the initial public commit of libunwind.

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

This is the same as c218c80c,
but for libcxxabi and libunwind.

This fixes running tests on Windows with Python installed in
e.g. "C:\Program Files\Python38".

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

This is not relevant for opaque pointers, and as such no longer
necessary.

This patch is making sure that we use getTopMostExitingLoop when
finding out which loops to forget, when dealing with
unswitchNontrivialInvariants and unswitchTrivialSwitch. It seems
to at least be needed for unswitchNontrivialInvariants as detected
by the included test case.

Note that unswitchTrivialBranch already used getTopMostExitingLoop.
This was done in commit 4a9cde5a. The commit
message in that commit says "If the patch makes sense, I will also
update those places to a similar approach ...", referring to these
functions mentioned above. As far as I can tell that never happened,
but this is an attempt to finally fix that.

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

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

All pointers are opaque now, so these are no longer necessary.

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

The 'ELPM' instruction has three forms:

--------------------------
| form        | feature  |
| ----------- | -------- |
| ELPM        | hasELPM  |
| ELPM Rd, Z  | hasELPMX |
| ELPM Rd, Z+ | hasELPMX |
--------------------------

The second form is always used in the expansion of pseudo instructions
LPMWRdZ/ELPMWRdZ. But for devices without ELPMX and with only ELPM,
only the first form can be used.

Reviewed By: aykevl, Miss_Grape

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