The vendor-defined XTHeadBb (predating the standard Zbb extension)
extension adds some bit-manipulation extensions with somewhat similar
semantics as some of the Zbb instructions.

It is supported by the C9xx cores (e.g., found in the wild in the
Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for XTHeadBb is
available from:
  https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da

Depends on D143036

Reviewed By: craig.topper

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

`bufferizesToMemoryWrite(OpResult)` looks for OpOperands that bufferize to memory writes inside the region of the defining op (if it has one). Currently, if the reverse use-def chain stops at any value inside of the region, the OpResult is considered to bufferize to a memory write.

It is always safe to have false positives among `bufferizesToMemoryWrite`, so the previous implementation is also correct. However, it can lead to additional buffer copies.

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

Don't compute the address of  element [0] of a vector when the vector
is empty, even if the address is not used.

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

It causes mysterious memory leaks when comparing std::string, see GitHub
Issue #60709 and the code review.

> All supported compilers support `consteval`, so there is no more need for the macro.
>
> Reviewed By: ldionne, Mordante, #libc
>
> Spies: libcxx-commits
>
> Differential Revision: https://reviews.llvm.org/D143489

This reverts commit aaef3b82.

The vendor-defined XTHeadBs (predating the standard Zbs extension)
extension adds a bit-test instruction (th.tst) with similar semantics
as bexti from Zbs.  It is supported by the C9xx cores (e.g., found in
the wild in the Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for XTHeadBs is
available from:
  https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da

Reviewed By: craig.topper

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

This patch reorder the list of Experimental Extensions in doc,
and change the spec verision in doc to match the actual Implementation

if this patch is so small that it is not worth to submit separately, Apologies for bothering

Reviewed By: craig.topper

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

Two of the float materialization patterns use the VSSRC regsiter class. This
register class is not available before Power 8. The patterns will stay the same
for Power 8 and up but must use the class F4RC for Power 7 and earlier.

This patch fixes those patterns.

Reviewed By: nemanjai, amyk, #powerpc

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

When both v8i64 and v4f16 are not legal in a v8i64->v8f16 conversion, legalizer will breaks it into v8i64->v4i64->v4f32->v8f32->v8f16.

Given we support v4i64->v8f16, we can combine them with a shuffle instruction.

Reviewed By: LuoYuanke

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

The revert reason is fixed in D143727 (test changes).

According to YAML specification keys must be unique for a mapping node:
"The content of a mapping node is an unordered set of key/value node pairs, with
the restriction that each of the keys is unique".

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

When an optional intrinsic scalar is passed to a function expecting an
unlimited polymorphic dummy argument, the presence test must be done
before the emboxing otherwise it will result in a program crash.

Depends on D143888

Reviewed By: jeanPerier, PeteSteinfeld

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

This patch fixes so that declspec attributes are forwarded
to the alias declaration.

Before this patch this would assert:

class Test { int a; };
using AlignedTest = __declspec(align(16)) const Test;
static_assert(alignof(AlignedTest) == 16, "error");

But afterwards it behaves the same as MSVC does and doesn't
assert.

Fixes: llvm/llvm-project#60513

Reviewed By: aaron.ballman

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

When emboxing an intrinsic type to a polymorphic descriptor, directly set its
type to `fir.class<none>`.

`fir.class<i32>` is not a real type used anywhere in lowering so make it right directly
avoid unnecessary convert op to `fir.class<none>`. Also `fir.class<i32>` would not be
recognized as unlimited polymorphic.

Reviewed By: jeanPerier, PeteSteinfeld

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

Fixes #60662 https://github.com/llvm/llvm-project/issues/60662

Allow ComplexType when create DenseElementsAttr.
Also allow build ConstantOp for integer complex.

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

The mid end will reassociate sub(sub(x, m1), m2) to sub(x, add(m1, m2)). This
reassociates it back to allow the creation of more mls instructions.

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

adjustFixedOrderRecurrences may insert instructions after immediately
after the PHI nodes in the block. This invalidates the phis() iterator.
To avoid crashing/accessing invalid recipes, first collect all
first-order recurrence phi recipes.

This should fix a crash reported by @dmgreen after D142589 landed.

Instead of destroying the object with allocator::destroy, we must
call its destructor directly. As a fly-by also mark LWG3008 as
fixed since it is handled by our implementation.

This was pointed out by Tim Song in https://reviews.llvm.org/D140913.

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

Don't call CheckCommonBlockDerivedType() recursively if the
derived type symbol is the same symbol that is already being
processed. This can happen when a component is a pointer of the
same type as its parent component, for instance.

Fixes #60230

Reviewed By: klausler

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

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

YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.

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

Revert rG0b0a38a7 : "[X86] combineX86ShufflesRecursively - don't widen shuffle subvector inputs"

Reports of miscompiles, that I'm still trying to triage - reverting for now

`alloc`s that have users outside of loops are guaranteed to fail in
`multibuffer`.

Instead of exposing ourselves to that failure in the transform dialect,
filter out the `alloc`s that fall in this category.

To be able to do this filtering we have to change the `multibuffer`
transform op from `TransformEachOpTrait` to a plain `TransformOp`. This is
because `TransformEachOpTrait` expects that every successful `applyToOne`
returns a non-empty result.

Couple of notes:
- I changed the assembly syntax to make sure we only get `alloc` ops as
  input. (And added a test case to make sure we reject invalid inputs.)
- `multibuffer` can still fail pretty easily when you know its limitations.
  See the updated `op failed to multibuffer` test case for instance.
  Longer term, instead of leaking/coupling the actual implementation (in
  this case the checks normally done in `memref::multiBuffer`) with the
  transform dialect (the added check in `::a...

The GPU plugins have a dependency on the device libraries. Sometimes we
cannot build the device libraries because the user does not have a valid
`clang` to use or it was explicitly disabled. Currently this leads to a
transitive failure because we cannot meet this dependency. This patch
simply removes that dependency.

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

Reviewed By: tianshilei1992

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

[lldb][Test][NFC] TestExternalCtorDtorLookup: add more instantiations to test linkage name is correct

D142712 added tests for when both lse2 and lse128 are available, but
in practice there is no way to enable LSE128 without LSE2 from clang:
LSE128 is a v9 only feature and LSE2 has been mandatory since v8.4,
and +/-lse2 can not be specified on the clang command line.

Therefore it makes more sense that lse2+lse128 should emit lse128
instructions, otherwise they will not be emitted at all.

It also makes sense to remove the lse128-only backend tests if that set
of attributes is never set by the frontend.

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

Reviewed By: Mordante, #libc

Spies: libcxx-commits, wenlei

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

Reapply "[AMDGPU] Modify adjustInliningThreshold to also consider the cost of passing function arguments through the stack"

Reapplies 142c28ff as part of D140242 which got reverted due to amdgpu openmp test failures.

This diff fixes said failures by eliding most of `adjustInliningThresholdUsingCallee` for indirect calls as the callee function is unavailable for indirect calls.

Reviewed By: arsenm, #amdgpu

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

Multibuffer will fail to apply on allocs that are used outside of loops.
This was properly caught in the current implementation but the way we report
it was broken.
Notes cannot be emitted on their own, they need to be attached to another
main diagnostic.

Long story short, change the severity of the report from Note to Error.

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

As a preparation for implementing DWARFv5 address ranges generation,
this patch refactors cloneAddressAttribute() method. It has special
handling for addresses which can be relocated in some unrelated value,
for applying relocations twice, for indexed addresses. Instead of
all these special handlings this patch uses general handling:

Read attribute value from InputDIE and apply PCOffset.

Another thing is that current handling of DW_FORM_addrx misses the
fact that relocations might be applied twice in some cases. This
patch fixes this problem also.

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

This change makes it possible to optionally provide a different callback to
determine if an instruction is materializable.

By default the behaviour is unchanged.

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

As originally implemented, the rematerialization of valid instructions across
the suspend point would iterate 4 times, meaning that up to 4 instructions could
be rematerialized.

This implementation changes that approach to instead build a graph of
rematerializable instructions, then move all of them. This is faster than the
original approach and is not limited to an arbitrary limit.

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

Added more tests that check for >4 instructions.
Also added a retcon-remat test that checks rematerialization into a suspend
block predecessor (such as when remat for a retcon suspend happens).

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

An RFC describing how -fstack-arrays will be implemented.

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

This duplicates some argument lowering and return value processing from
flang/lib/Lower/ConvertCall.cpp. The existing code in CovertCall lowers
directly into the fir.call (without the hlfir transformational intrinsic
operation), and it is too tied to the lowering code to move into
flang/lib/Optimizer to allow for more complete re-use here.

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

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

Add an HLFIR operation for the SUM transformational intrinsic, according
to the design set out in flang/doc/HighLevelFIR.md.

I decided to make hlfir.sum very lenient about the form of its
arguments. This allows the sum intrinsic to be lowered to only this HLFIR
operation, without needing several operations to convert and box
arguments. Having only one operation generated for the intrinsic
invocation should make optimisation passes on HLFIR simpler.

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