When built without LLVM_ENABLE_ASSERTIONS we can get a warning in
ARMExpandPseudoInsts.cpp due to a variable only being used inside
of a LLVM_DEBUG statement. Fix this with a dummy use, like we do
elsewhere.

Support extra concrete class declarations and definitions under NativeTrait that get injected into the class that specifies the trait. Extra declarations and definitions can be passed in as template arguments for NativeOpTraitNativeAttrTrait and NativeTypeTrait.

Usage examples of this feature include:

- Creating a wrapper Trait for authoring inferReturnTypes with the OpAdaptor by specifying necessary Op specific declarations and definitions directly in the trait
- Refactoring the InferTensorType trait

Reviewed By: jpienaar

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

Disassembling needs LLVM_TARGETS_TO_BUILD.

reduction operator min and max are not supported with complex type.
Add a proper error so it fails correctly.

Reviewed By: razvanlupusoru

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

This came up in This came up in
https://reviews.llvm.org/D146776#inline-1489091 and is slightly related
to https://reviews.llvm.org/D153855. In both patches, there is the
observation that some modifications of the module should not invalidate
analysis, such as when adding a declaration or some metadata the won't
be used when compiling the current module.

This patch implements the suggestion that we should ignore globals that have
the `llvm.` prefix when calculating the module hash.

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

Reviewed By: aeubanks

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

MachineLICM pass handles inner loops only when outmost loop does not have unique
predecessor. If the loop has preheader and there is loop invariant code, the
invariant code can be hoisted to the preheader in general. This patch makes the
pass handle inner loops in general.

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

If the operands to the mul have other uses we may be extending their
live range past a kill flag.

Reviewed By: asb, asi-sc

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

For RISC-V, getRegisterType for fp16 returns i16. i16->fp64 extload
is considered legal because the LoadExtActions defaults to Legal
for all entries. Only fp/fp and int/int entries are changed to
Expand fore RISC-V.

This patch detects the FP-ness has changed and won't try to call
isLoadExtLegal.

Alternatively, we could add Expand for int/fp and fp/int, but that
seemed a little silly.

Fixes #63816

Reviewed By: asb, wangpc

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

I don't believe this is relevant anymore with opaque pointers,
where we always expand the entire offset, without splitting it into
parts.

This folds (a << k) ? 2^k * a : 0 to 2^k * a.

https://alive2.llvm.org/ce/z/_dDRjo

Fix #62155.

Reviewed By: nikic

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

Do not hoist vector transfers that do not match exactly. In particular, do not hoist transfers with different vector types. This has lead to invalid IR (yielded vector type is different from iter_arg type) in downstream projects.

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

/Users/jiefu/llvm-project/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp:293:13: error: function 'FactorOutConstant' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static bool FactorOutConstant(const SCEV *&S, const SCEV *&Remainder,
            ^
1 error generated.

In D146869 @arsenm pointed out that the constrained intrinsics aren't
getting the strictfp attribute by default. They should be since they are
required to have it anyway.

TableGen did not know about this attribute until now. This patch adds
strictfp to TableGen, and it uses it on all of the constrained intrinsics.

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

This also removes the element type from the descriptor, as it is
always i8. The meaning of the step is now the same between
integers and pointers.

The `static_(num_threads|tile_sizes)` attributes of this op are
`DefaultValuedOptionalAttr`s, so they can be constructed *without* such
an attribute. In other words, the following is a valid op (note the
absense of the `static_num_threads` attribute):

"builtin.module"() ({
  "transform.sequence"() <{failure_propagation_mode = 1 : i32, operand_segment_sizes = array<i32: 0, 0>}> ({
  ^bb0(%arg0: !pdl.operation, %arg1: !transform.op<"linalg.matmul">, %arg2: !transform.op<"linalg.elemwise_binary">):
    %0 = "transform.structured.match"(%arg0) <{ops = ["test.dummy"]}> : (!pdl.operation) -> !pdl.operation
    %1:2 = "transform.structured.tile_to_forall_op"(%arg1, %0) <{operand_segment_sizes = array<i32: 1, 0, 0, 0, 1>}> : (!transform.op<"linalg.matmul">, !pdl.operation) -> (!transform.op<"scf.forall">, !transform.op<"linalg.matmul">)
    "transform.yield"() : () -> ()
  }) : () -> ()
}) : () -> ()

However, the custom printing directive converted those to an `ArrayRef`,
which crashes if done on an empty `ArrayAttr`. This patch changes the
signature such that no automatic conversion takes place and extends the
test to test for existinnce of the attribute.

Reviewed By: nicolasvasilache

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

Record the SP adjustment on entry to each basic block. This is almost
always zero except on targets like ARM which can split a basic block in
the middle of a call sequence.

This simplifies PEI::replaceFrameIndices which previously had to visit
basic blocks in a specific order and had special handling for
unreachable blocks. More importantly it paves the way for an equally
simple implementation of a backwards version of replaceFrameIndices,
which is required to fully convert PrologEpilogInserter to backwards
register scavenging, which is preferred because it does not rely on
accurate kill flags.

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

Avoid duplicate calls to setTargetAttributes on global variable definitions.

Differential: https://reviews.llvm.org/D153903

`KnownBits` is also a type name. Having a field with this name
prevents derived classes from using the `KnownBits` type unless they use `struct KnownBits`.

Reviewed By: foad

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

https://reviews.llvm.org/D130883 introduced MIMetadata to simplify
metadata propagation (DebugLoc and PCSections).

However, we're currently still permitting implicit conversion of
DebugLoc to MIMetadata, to allow for a gradual transition and let the
old code work as-is.

This manifests in lost !pcsections metadata for X86-specific lowerings.
For example, 128-bit atomics.

Fix the situation for X86ISelLowering by converting all BuildMI() calls
to use an explicitly constructed MIMetadata.

Reviewed By: dvyukov

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

Add the scalar addressing mode for multi vector LD1 instructions.

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

getPtx used to return `const char*`. It is not flexible when one needs to build string in the function. This work changes return type.

Reviewed By: springerm

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

Arm Performance Libraries contain math library which provides
vectorized versions of common math functions.
This patch allows to use it with clang and llvm via -fveclib=ArmPL or
-vector-library=ArmPL, so loops with such calls can be vectorized.
The executable needs to be linked with the amath library.

Arm Performance Libraries are available at:
https://developer.arm.com/Tools%20and%20Software/Arm%20Performance%20Libraries

Reviewed by: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D154508

`ptxas` complains with . in the function name, so we delete. Also, it expects return i64.

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

Opaque pointers mode is enabled by default, no need to explicitly
enable it.

This moves the formatting job to a shell script, which should also fix
the clang pre-commit CI.

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

This reverts commit 593797ab.

I didn't realize that there was already a fix for the broken tests fd2254b7.

As in D140287, we can now generate umull from mul(zext(x), y) in cases where we
know that the top bits of y are zero. This teaches that to the cost model,
adjusting how isWideningInstruction detects mul operations that can extend both
operands. This helps for constants and other cases where the operands of the
mul are known to be extended, but not directly extends.

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

This regresses with opaque pointers. I'll submit a patch to recover
the regression.

This extends DWARFDebugLine to properly parse line number programs with
maximum_operations_per_instruction > 1 for VLIW targets.

No functions that use that parsed output to retrieve line information
have been extended to support multiple op-indexes. This means that when
retrieving information for an address with multiple op-indexes, e.g.
when using llvm-addr2line, the penultimate row for that address will be
used, which in most cases is the row for the second largest op-index.
This will be addressed in further changes, but this patch at least
allows us to correctly parse such line number programs, with a warning
saying that the line number information may be incorrect (incomplete).

Reviewed By: StephenTozer

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

This reverts commit 14c3ab94.

Causes build bot failures.

It's the only combine (AFAIK) that didn't use an apply function.
There is no reason for it to mutate instructions in the matcher, so split it up.

Reviewed By: aemerson, arsenm

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

This patch migrates the UseDevicePtr and UseDeviceAddr clause related code for handling privatisation from Clang codegen to the OMPIRBuilder

Depends on D150860

Reviewed By: jdoerfert

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

Reviewed By: arsenm

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

Currently when compiling for an execute-only target without movt then
EmitStructByval will generate a constant pool load which isn't
compatible with execute-only. Handle this by emitting tMOVi32imm,
and also simplify the existing movt handling by emitting t2MOVi32imm
or MOVi32imm.

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

The expansion of the various MOVi32imm pseudo-instructions works by
splitting the operand into components (either halfwords or bytes) and
emitting instructions to combine those components into the final
result. When the operand is an immediate with some components being
zero this can result in pointless instructions that just add zero.

Avoid this by restructuring things so that a separate function handles
splitting the operand into components, then don't emit the component
if it is a zero immediate. This is straightforward for movw/movt,
where we just don't emit the movt if it's zero, but the thumb1
expansion using mov/add/lsl is more complex, as even when we don't
emit a given byte we still need to get the shift correct.

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

This patch precommits a test for:
https://reviews.llvm.org/D148420

Reviewed By: nikic

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