This fixes a build failure with assertions disabled.

[Originally committed as f6ddf778;
reverted in bbef3835 due to test
breakage; now relanded with the Arm tests conditioned on
`arm-registered-target`]

The LowerTypeTests pass emits a jump table in the form of an
`inlineasm` IR node containing a string representation of some
assembly. It tests the target triple to see what architecture it
should be generating assembly for. But that's not good enough for
`Triple::thumb`, because the 32-bit PC-relative `b.w` branch
instruction isn't available in all supported architecture versions. In
particular, Armv6-M doesn't support that instruction (although the
similar Armv8-M Baseline does).

Most of this patch is concerned with working out whether the
compilation target is Armv6-M or not, which I'm doing by going through
all the functions in the module, retrieving a TargetTransformInfo for
each one, and querying it via a new method I've added to check its
SubtargetInfo. If any function's TTI indicates that it's targeting an
architecture supporting B.W, then we assume we're also allowed to use
B.W in the jump table.

The Armv6-M compatible jump table format requires a temporary
register, and therefore also has to use the stack in order to restore
that register.

Another consequence of this change is that jump tables on Arm/Thumb
are no longer always the same size. In particular, on an architecture
that supports Arm and Thumb-1 but not Thumb-2, the Arm and Thumb
tables are different sizes from //each other//. As a consequence,
``getJumpTableEntrySize`` can no longer base its answer on the target
triple's architecture: it has to take into account the decision that
``selectJumpTableArmEncoding`` made, which meant I had to move that
function to an earlier point in the code and store its answer in the
``LowerTypeTestsModule`` class.

Reviewed By: lenary

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

There is no need to update the AlsoPack field when creating
VPReplicateRecipes. It can be easily computed based on the VP def-use
chains when it is needed.

Reviewed By: Ayal

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

Connect the hoistRedundantVectorTransfers functionality to the transform
dialect.

Authored-by: Quentin Colombet <quentin.colombet@gmail.com>

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

InstCombine is supposed to be a superset of InstSimplify, but
failed to invoke load simplification.

Unfortunately, this causes a minor compile-time regression, which
will be mitigated in a future commit.

Seems that it's a more appropriate place to do this transform.

These show that we currently fail to call load simplification from
InstCombine.

define i1 @compare_vscales() {
  %vscale = call i64 @llvm.vscale.i64()
  %vscalex2 = shl nuw nsw i64 %vscale, 1
  %vscalex4 = shl nuw nsw i64 %vscale, 2
  %cmp = icmp ult i64 %vscalex2, %vscalex4
  ret i1 %cmp
}

This IR is currently emitted by LLVM. This icmp is redundant as this snippet
can be simplified to true or false as both operands originate from the same
@llvm.vscale.i64() call.

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

I stumbled over this while trying to improve our exit count work. These expressions
are equivalent for complementary signed/unsigned ext and min/max (including umin_seq),
but they are not canonicalized and SCEV cannot recognize them as the same.

The benefit of this canonicalization is that SCEV can prove some new equivalences which
it coudln't prove because of different forms. There is 1 test where trip count seems pessimized,
I could not directly figure out why, but it just seems an unrelated issue that we can fix.
Other changes seem neutral or positive to me.

Differential Revision: https://reviews.llvm.org/D141481
Reviewed By: nikic

Note that those functions on the left hand side are soft-deprecated in
favor of those on the right hand side:

  getMinSignedBits -> getSignificantBits
  getNullValue     -> getZero
  isNullValue      -> isZero
  isOneValue       -> isOne

The uniformity analysis treated an undef argument to phi to be distinct from any
other argument, equivalent to calling PHINode::hasConstantValue() instead of
PHINode::hasConstantOrUndefValue(). Such a phi was reported as divergent. This
is different from the older divergence analysis which treats such a phi as
uniform. Fixed uniformity analysis to match the older behaviour.

The original behaviour was added to DivergenceAnalysis in D19013. But it is not
clear if relying on the undef value is safe. The defined values are not constant
per se; they just happen to be uniform and the non-constant uniform value may
not dominate the PHI.

Reviewed By: ruiling

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

When calling PointerAssociateRemapping the dynamic type information
from the target needs to be carried over to the pointer if any.

Reviewed By: klausler

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

Fold LoadInst for uniformly initialized constants, even if there
are non-constant GEP indices.

Goal proof: https://alive2.llvm.org/ce/z/oZtVby

Motivated by https://github.com/rust-lang/rust/issues/107208

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

The libc uses some functions that GCC does not currently
implement, that come from Arm's ACLE header usually.

These are:
```
__arm_wsr64
__arm_rsr64
__arm_wsr
__arm_rsr
```

This issue was reported to us (https://github.com/llvm/llvm-project/issues/60473)
and I've then reported that back to GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642).

Even if these functions are added, clang has some non standard extensions
to them that gcc may not take. So we're looking at a fix in gcc 13 at best,
and that may not be enough for what we're doing with them.

So I've added ifdefs to use alternatives with gcc.

For handling the stack pointer, inline assembly is unfortunately the only option.
I have verified that the single mov is essentially what __arm_rsr64 generates.

For fpsr and fpcr the gcc devs suggested using
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/AArch64-Built-in-Functions.html#AArch64-Built-in-Functions.

Reviewed By: sivachandra

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

For D144184.

This revision adds atomic support to the StoreOp. It chooses
to print the atomic keywords together with the syncscope and
ordering arguments. The revision also implements verifiers to
ensure the constraints that apply to atomic store operations
are checked.

Depends on D144112

Reviewed By: Dinistro

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

Note that getMinSignedBits has been soft-deprecated in favor of
getSignificantBits.

The `IsImplicit` parameter should be removed since it is not used now.

Note that isAllOnesValue has been soft-deprecated in favor of
isAllOnes.

Sema::DirectModuleImports is not used now. Remove it for clearness.

Note that isOneValue has been soft-deprecated in favor of isOne.

Note that getAllOnesValue has been soft-deprecated in favor of
getAllOnes.

Note that APInt::getNullValue has been soft-deprecated in favor of
APInt::getZero.

Since canonicalizeForInvariantConditionInjection is introduced the
in loop successor may be the second successor.

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

Note that APInt::isNullValue has been soft-deprecated in favor of
APInt::isZero.

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

Previously, we will mark all the declarations in the GMF as not visible
to other module units. But this is too strict and the users may meet
problems during the template instantiation like the above exampel shows.
The patch addresseds the problem.

Adds support for these SCEVs to cover more cases.

Differential Revision: https://reviews.llvm.org/D143259
Reviewed By: dmakogon, fhahn

Adding load and store tests. Addressing post commit feedback.

Following recent changes to remove non-core legacy passes.

Don't include llvm-driver when building for Windows

New:
```
module mh1
    (input var int in1,
     input var in2, in3,
     output tagged_st out);
endmodule
```

Old:
```
module mh1
    (input var int in1, input var in2, in3, output tagged_st out);
endmodule
```

`getNextNonComment` was modified to return a non-const pointer because
we needed to use it that way in `verilogGroupDecl`.

The comment on line 2626 was a typo.  We corrected it while modifying
the function.

Reviewed By: MyDeveloperDay

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

As we discussed before, we should stop supporting
std::experimental::coroutine_traits in clang17. Now the clang16 is
branched so we can clean them now.

All the removed tests have been duplicated before.

`include/llvm/CodeGen/TargetGlobalISel.td` no longer exists.

Provides a small code size savings for some f32 cases.

The MacOS problem has been fixed. Additionally, don't enable the
driver build on Windows. We can look into enabling it later if
symlinks work better than I think on Windows.

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

We do match source modifiers for f32 typed selects already, but the
combiner code was never informed of this.

A long time ago the documentation lied and stated that source
modifiers don't work for v_cndmask_b32 when they in fact do. We had a
bunch fo code operating under the assumption that they don't support
source modifiers, so we tried to move fnegs around to work around
this.

Gets a few small improvements here and there. The main hazard to watch
out for is infinite loops in the combiner since we try to move fnegs
up and down the DAG. For now, don't fold fneg directly into select.
The generic combiner does this for a restricted set of cases
when getNegatedExpression obviously shows an improvement for both
operands. It turns out to be trickier to avoid infinite looping the
combiner in conjunction with pulling out source modifiers, so
leave this for a later commit.

This fixes a corner case where we would skip doing an alias check because of a
>= vs > bug, due to the presence of a non-aliasing instruction, in this case
the load %safeld.

Fixes issue #59376