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

`__gnu_h2f_ieee` and `__gnu_f2h_ieee` are introduce by ARM and set that as
default name for fp16 and fp32 conversion in LLVM.

However RISC-V GCC using default naming scheme for that, which is
`__extendhfsf2` and `__truncsfhf2` for that, that cause runtime ABI
incompatible issue.

Although we didn't have formal runtime ABI spec to specify those naming
convention yet, but I think it would be great to fix the incompatible
issue first.

And I've plan to create a runtime ABI spec undere psABI spec this year.

Reviewed By: asb

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

detatch -> detach. As this requires touching all uses, also
lower-case it in accordance with the style guide.

Now that loads always have an alignment, we should not perform an
ABI alignment fallback here.

extract_vec_elt (load X), C --> scalar load (X+C)

As noted in the comment, DAGCombiner has this fold -- and the code in this
patch is adapted from DAGCombiner::scalarizeExtractedVectorLoad() -- but
x86 should benefit even if the loaded vector has other uses as long as we
apply some other x86-specific conditions. The motivating example from #50310
is shown in vec_int_to_fp.ll.

Fixes #50310

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

Where the instruction mnemonic contains a dot, we name the corresponding
instruction in the .td file using a _ in the place of the dot. e.g. LR_W
rather than LRW. This commit updates RISCVInstrInfoZb.td to follow that
convention.

Reviewed By: kito-cheng

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

We should abort this walk if we hit any instruction that is not
guaranteed to transfer.

In this case, we have no guarantee that the load is unconditionally
executed, so the argument promotion is not legal.

Shiny new DBG_PHI instruction usually have physical registers as operands
-- however, the machine verifier checks to see whether they're live, and
occasionally this fails. There's a filter for DBG_VALUE instructions to not
get verified in this way: expand it to exempt all debug instructions from
liveness checking, which means DBG_PHIs get treated like DBG_VALUEs.

This also future proofs against us adding new debug instructions.

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

If we don't demand the upper elements of the 256-bit vector, then just perform as a 128-bit vector

As suggested on D117898

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

This function used to be shared with the Attributor, but can now
be made private.

This patch updates how splat loads handled and is an extension of D106555.

Particularly, for v2i64/v4f32/v4i32 types, they are updated to handle only
non-extending loads. For v8i16/v16i8 types, they are updated to handle extending
loads only if the memory VT is the same vector element VT type.

A test case has been added to illustrate a scenario where a PPCISD::LD_SPLAT
node should not be produced. In this test, it depicts the following f64
extending load used in a v2f64 build vector, but the extending load is actually
used in more places other than the build vector (such as in t12 and t16).
```
Type-legalized selection DAG: %bb.0 'test:entry'
SelectionDAG has 20 nodes:
  t0: ch = EntryToken
  t4: i64,ch = CopyFromReg t0, Register:i64 %1
  t6: i64,ch = CopyFromReg t0, Register:i64 %2
  t11: f64,ch = load<(load (s64) from %ir.b, !tbaa !7)> t0, t4, undef:i64
        t16: f64 = fadd t31, t37
      t34: ch = store<(store (s64) into %ir.c, !tbaa !7)> t31:1, t16, t6, undef:i64
    t36: ch = TokenFactor t34, t37:1
    t27: v2f64 = BUILD_VECTOR t37, t37
  t22: ch,glue = CopyToReg t36, Register:v2f64 $v2, t27
      t12: f64 = fadd t11, t37
    t28: ch = store<(store (s64) into %ir.b, !tbaa !7)> t11:1, t12, t4, undef:i64
  t31: f64,ch = load<(load (s64) from %ir.c, !tbaa !7)> t28, t6, undef:i64
    t2: i64,ch = CopyFromReg t0, Register:i64 %0
  t37: f64,ch = load<(load (s32) from %ir.a, !tbaa !3), anyext from f32> t0, t2, undef:i64
  t23: ch = PPCISD::RET_FLAG t22, Register:v2f64 $v2, t22:1
```

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

When a comparison is extended and it would be free to extend the
arguments to that comparison, we can propagate the extend into those arguments.
This prevents extra instructions being generated to extend the result of the
comparison, which is not free to extend.

This is a resubmission of D116812 with fixes that need another review.

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

Fixes a false positive that occurs when a user-implemented memmove is
instrumented by HWASan.

Reviewed By: vitalybuka

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

This is a minimal test to show a transform proposed in D118376.

Fix buildbot failure https://lab.llvm.org/buildbot/#/builders/160

Using a _BitInt (or _ExtInt) type as a block parameter or block return
type hits an "unreachable" when trying to determine the encoding for
the block. Instead of crashing, this patch handles it like some of the
other types for which we don't yet have an encoding. The test case
verifies we no longer crash, but does not verify that we provide any
particular encoding (it can be updated once someone more familiar with
ObjC steps in to define the encoding).

Fixes PR50503.

[X86] combineSetCCMOVMSK - don't fold MOVMSK(BITCAST(PCMPEQ(X,0))) -> PTESTZ(X,X) if we're not testing every element comparison

We can't fold MOVMSK(BITCAST(PCMPEQ(X,0))) -> PTESTZ(X,X) if we're not testing every element comparison

Adds patterns of the form "(and a, (not b)) -> bic".

NOTE: With this support I'm inclined to remove AArch64ISD::BIC,
but will leave that investigation for another time.

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

This commutative test could be optimised into:
  index z0.d, x0, x1

But currently isn't yet.

This updates NewGVN test cases that were running
  "opt -basic-aa -newgvn ..."
to run
  "opt -passes=newgvn ..."
instead.

The pipeline will be more similar to what we used to have with
legacy PM by doing it this way. The compatility mode that we've
been using for awhile during transition from legacy PM to new PM,
i.e. using the legacy syntax together with new PM, has resulted in
a pipeline such as
  -passes='function(require<basic-aa>),function(newgvn)'
but running the analysis in a separate function pass manager seem
overly complicated for these tests.

Another difference is that we will get the default aa-pipeline instead
of only running basic-aa. That might be a bit questioned (given that
the tests originally specified basic-aa). The output is however
identival for all the test cases modified here regardless of using
basic-aa or the default aa-pipeline.

This is also another small step towards removal of the support for
using the legacy PM syntax in opt.

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

Use the new PM syntax when specifying the pipeline in regression
tests previously running
  "opt -newgvn ..."

Instead we now do
  "opt -passes=newgvn ..."

Notice that this also changes the aa-pipeline to become the default
aa-pipeline instead of just basic-aa. Since these tests haven't been
explicitly requesting basic-aa in the past (compared to the test cases
updated in a separate patch involving "-basic-aa -newgvn") it is
assumed that the exact aa-pipeline isn't important for the validity
of the test cases. An alternative could have been to add
-aa-pipeline=basic-aa as well to the run lines, but that might just
add clutter in case the test cases do not care about the aa-pipeline.

This is another step to move away from the legacy PM syntax when
specifying passes in opt.

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

These splats -- whether BUILD_VECTOR or SPLAT_VECTOR -- are formed by
first extracting a value from a vector and splatting it to all elements
of the destination vector. These could be performed more optimally,
avoiding the drop to scalar, using RVV's vrgather, for example.

The LMULMAX check names didn't match the options we were passing to llc
(they were swapped around) and we were silently missing coverage for one
test which differs between RV32 and RV64.

This patch introduces a new options for script llvm-mca-compare.py
(-plot-resource-pressure, -plot) to draw plots for llvm-mca tool
statistics and option (--plot-path) to specify relative path where
you want to save the plots.

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

Previous folds by combineSetCCMOVMSK might have converted these to CMP when changing the bitwidth, and the CMP->SUB fold might not have happened (or will happen)

SortJavaScriptImports attempts to set its currently parsed token to an
invalid token when it reaches the end of the line. However in doing so,
it used a `FormatToken`, which contains a `Token Tok`. `Token` does not
have a constructor, so its fields start out as uninitialized memory.

`Token::startToken()` initializes all fields. Calling it in
`JavaScriptImportSorter`'s constructor thus fixes the problem.

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

Add missing test coverage for `sub nuw` combined with both unsigned and
signed predicates.

Currently, basic AA has special support for llvm.memcpy.* intrinsics. This change extends this support for any memory trancsfer opration and in particular llvm.memmove.* intrinsic.

Reviewed By: reames, nikic

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

It causes builds to fail with

llvm/include/llvm/Support/Casting.h:269:
typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*)
[with X = llvm::IntegerType; Y = const llvm::Type; typename llvm::cast_retty<X, Y*>::ret_type = const llvm::IntegerType*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

See the code review for link to a reproducer.

> This patch introduces folding of and-reduce idiom and generates code
> that is easier to read and which is lest costly in terms of icmp operations.
> The folding is
> ```
>   icmp eq (bitcast(icmp ne (lhs, rhs)), 0)
> ```
> into
> ```
>   icmp eq(bitcast(lhs), bitcast(rhs))
> ```
>
> See PR53419.
>
> Differential Revision: https://reviews.llvm.org/D118317
> Reviewed By: lebedev.ri, spatel

This reverts commit 8599bb0f.

This also revertes the dependent change:

"[Test] Add 'ne' tests for and-reduce pattern folding"

This reverts commit a4aaa599.

On the level of the generated object files, both symbols (both
original and alias) are generally indistinguishable - both are
regular defined symbols. But previously, only the original
function had the COFF ComplexType set to IMAGE_SYM_DTYPE_FUNCTION,
while the symbol created via an alias had the type set to
IMAGE_SYM_DTYPE_NULL.

This matches what GCC does, which emits directives for setting the
COFF symbol type for this kind of alias symbol too.

This makes a difference when GNU ld.bfd exports symbols without
dllexport directives or a def file - it seems to decide between
function or data exports based on the COFF symbol type. This means
that functions created via aliases, like some C++ constructors,
are exported as data symbols (missing the thunk for calling without
dllimport).

The hasnt been an issue when doing the same with LLD, as LLD decides
between function or data export based on the flags of the section
that the symbol points at.

This should fix the root cause of
https://github.com/msys2/MINGW-packages/issues/10547.

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

rG9103b73f was assuming that we could OR/AND with the source vector, but that will fail on float/double vectors without bitcasting - it also missed the case that any_of checks might be testing less than all the source elements

BEGIN_PUBLIC
[mlir] Move SCF utils implementations to SCF/Utils.
END_PUBLIC

clang-format: [JS] sort import aliases. Users can define aliases for long symbols using import aliases:

    import X = A.B.C;

Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.

Aliases are not sorted within their group, as they may reference each
other, so order is significant.

This reverts commit f750c3d9. It fixes
the msan issue by not parsing past the end of the line when handling
import aliases.

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