[MachineVerifier] Try harder to verify LiveIntervals

Verify the LiveIntervals analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
t

[MachineVerifier] Try harder to verify LiveIntervals

Verify the LiveIntervals analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
that would use the analysis.

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

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

show more ...

[MachineVerifier] Verify liveins for live-through segments

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

Restore CodeGen/LowLevelType from `Support`

This is rework of;
- D30046 (LLT)

Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen`
may depend on `CodeGen`.

`LowLevlType.h` origina

Restore CodeGen/LowLevelType from `Support`

This is rework of;
- D30046 (LLT)

Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen`
may depend on `CodeGen`.

`LowLevlType.h` originally belonged to `CodeGen`. Almost all userse are
still under `CodeGen` or `Target`. I think `CodeGen` is the right place
to put `LowLevelType.h`.

`MachineValueType.h` may be moved as well. (later, D149024)

I have made many modules depend on `CodeGen`. It is consistent but
inefficient. It will be split out later, D148769

Besides, I had to isolate MVT and LLT in modmap, since
`llvm::PredicateInfo` clashes between `TableGen/CodeGenSchedule.h`
and `Transforms/Utils/PredicateInfo.h`.
(I think better to introduce namespace llvm::TableGen)

Depends on D145937, D146352, and D148768.

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

show more ...

Fix uninitialized class members

Reviewed By: LuoYuanke

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

Fix uninitialized pointer members in CodeGen

This change initializes the members TSI, LI, DT, PSI, and ORE pointer feilds of the SelectOptimize class to nullptr.

Reviewed By: LuoYuanke

Differentia

Fix uninitialized pointer members in CodeGen

This change initializes the members TSI, LI, DT, PSI, and ORE pointer feilds of the SelectOptimize class to nullptr.

Reviewed By: LuoYuanke

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

show more ...

[MachineVerifier] Try harder to verify SlotIndexes

Verify the SlotIndexes analysis after a pass that claims to preserve it,
even if there are no further passes (apart from the verifier itself)
that

[MachineVerifier] Try harder to verify SlotIndexes

Verify the SlotIndexes analysis after a pass that claims to preserve it,
even if there are no further passes (apart from the verifier itself)
that would use the analysis.

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

show more ...

[llvm] add CallBrPrepare pass to pipelines

Capstone of
https://discourse.llvm.org/t/rfc-syncing-asm-goto-with-outputs-with-gcc/65453/8

Clang changes are still necessary to enable the use of outputs

[llvm] add CallBrPrepare pass to pipelines

Capstone of
https://discourse.llvm.org/t/rfc-syncing-asm-goto-with-outputs-with-gcc/65453/8

Clang changes are still necessary to enable the use of outputs along
indirect edges of asm goto statements.

Link: https://github.com/llvm/llvm-project/issues/53562

Reviewed By: void

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

show more ...

[PowerPC][GISel] add support for fpconstant

Reviewed By: arsenm

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

Lift EHPersonalities from Analysis to IR (NFC)

Computing EH-related information was only relevant for analysis passes so far. Lifting it to IR will allow the IR Verifier to calculate EH funclet colo

Lift EHPersonalities from Analysis to IR (NFC)

Computing EH-related information was only relevant for analysis passes so far. Lifting it to IR will allow the IR Verifier to calculate EH funclet coloring and validate funclet operand bundles in a follow-up step.

Reviewed By: rnk, compnerd

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

show more ...

[MC] Make more use of MCInstrDesc::operands. NFC.

Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A futu

[MC] Make more use of MCInstrDesc::operands. NFC.

Change MCInstrDesc::operands to return an ArrayRef so we can easily use
it everywhere instead of the (IMHO ugly) opInfo_begin and opInfo_end.
A future patch will remove opInfo_begin and opInfo_end.

Also use it instead of raw access to the OpInfo pointer. A future patch
will remove this pointer.

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

show more ...

[CodeGen] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFC

Use isPhysical/isVirtual methods.

Reviewed By: foad

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

[GlobalISel] Add a new G_INVOKE_REGION_START instruction to fix an EH bug.

We currently have a bug where the legalizer, when dealing with phi operands,
may create instructions in the phi's incoming

[GlobalISel] Add a new G_INVOKE_REGION_START instruction to fix an EH bug.

We currently have a bug where the legalizer, when dealing with phi operands,
may create instructions in the phi's incoming blocks at points which are effectively
dead due to a possible exception throw.

Say we have:

throwbb:
EH_LABEL
x0 = %callarg1
BL @may_throw_call
EH_LABEL
B returnbb

bb:
%v = phi i1 %true, throwbb, %false....

When legalizing we may need to widen the i1 %true value, and to do that we need
to create new extension instructions in the incoming block. Our insertion point
currently is the MBB::getFirstTerminator() which puts the IP before the unconditional
branch terminator in throwbb. These extensions may never be executed if the call
throws, and therefore we need to emit them before the call (but not too early, since
our new instruction may need values defined within throwbb as well).

throwbb:
EH_LABEL
x0 = %callarg1
BL @may_throw_call
EH_LABEL
%true = G_CONSTANT i32 1 ; <<<-- ruh'roh, this never executes if may_throw_call() throws!
B returnbb

bb:
%v = phi i32 %true, throwbb, %false....

To fix this, I've added two new instructions. The main idea is that G_INVOKE_REGION_START
is a terminator, which tries to model the fact that in the IR, the original invoke inst
is actually a terminator as well. By using that as the new insertion point, we
make sure to place new instructions on always executing paths.

Unfortunately we still need to make the legalizer use a new insertion point API
that I've added, since the existing `getFirstTerminator()` method does a reverse
walk up the block, and any non-terminator instructions cause it to bail out. To
avoid impacting compile time for all `getFirstTerminator()` uses, I've added a new
method that does a forward walk instead.

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

show more ...

[GlobalISel] Better verification of G_UNMERGE_VALUES

Verify three cases of G_UNMERGE_VALUES separately:

1. Splitting a vector into subvectors (the converse of
G_CONCAT_VECTORS).
2. Splitting a v

[GlobalISel] Better verification of G_UNMERGE_VALUES

Verify three cases of G_UNMERGE_VALUES separately:

1. Splitting a vector into subvectors (the converse of
G_CONCAT_VECTORS).
2. Splitting a vector into its elements (the converse of
G_BUILD_VECTOR).
3. Splitting a scalar into smaller scalars (the converse of
G_MERGE_VALUES).

Previously #1 allowed strange combinations like this:
%1:_(<2 x s16>),%2:_(<2 x s16>) = G_UNMERGE_VALUES %0(<2 x s32>)
This has been tightened up to check that the source and destination
element types match, and some MIR test cases updated accordingly.

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

show more ...

[GlobalISel] Remove semantic operand of G_IS_FPCLASS

Instruction G_IS_FPCLASS had an operand that represented floating-point
semantics of its first operand. It allowed types that have the same lengt

[GlobalISel] Remove semantic operand of G_IS_FPCLASS

Instruction G_IS_FPCLASS had an operand that represented floating-point
semantics of its first operand. It allowed types that have the same length,
like `bfloat16` and `half`, to be distinguished. Unfortunately, it is
not sufficient, as other operation still cannot distinguish such types.
Solution of this problem must be more general, so now this operand is removed.

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

show more ...

[TableGen] Use MemoryEffects to represent intrinsic memory effects (NFCI)

The TableGen implementation was using a homegrown implementation of
FunctionModRefInfo. This switches it to use MemoryEffect

[TableGen] Use MemoryEffects to represent intrinsic memory effects (NFCI)

The TableGen implementation was using a homegrown implementation of
FunctionModRefInfo. This switches it to use MemoryEffects instead.
This makes the code simpler, and will allow exposing the full
representational power of MemoryEffects in the future. Among other
things, this will allow us to map IntrHasSideEffects to an
inaccessiblemem readwrite, rather than just ignoring it entirely
in most cases.

To avoid layering issues, this moves the ModRef.h header from IR
to Support, so that it can be included in the TableGen layer.

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

show more ...

[IR] Switch everything to use memory attribute

This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemo

[IR] Switch everything to use memory attribute

This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.

The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.

High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.

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

show more ...

[MachineVerifier] Try harder to verify LiveVariables

Verify the LiveVariables analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
t

[MachineVerifier] Try harder to verify LiveVariables

Verify the LiveVariables analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
that would use the analysis.

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

show more ...

Revert "[MachineVerifier] Try harder to verify LiveVariables"

This reverts commit d4650d0938e290ca9d6544d6b07da2fb7156762d.

Reverted because it causes several X86 CodeGen test failures in a build
w

Revert "[MachineVerifier] Try harder to verify LiveVariables"

This reverts commit d4650d0938e290ca9d6544d6b07da2fb7156762d.

Reverted because it causes several X86 CodeGen test failures in a build
with LLVM_ENABLE_EXPENSIVE_CHECKS=ON.

show more ...

[MachineVerifier] Try harder to verify LiveVariables

Verify the LiveVariables analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
t

[MachineVerifier] Try harder to verify LiveVariables

Verify the LiveVariables analysis after a pass that claims to preserve
it, even if there are no further passes (apart from the verifier itself)
that would use the analysis.

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

show more ...

[GlobalISel] Enforce G_ASSERT_ALIGN to have a valid alignment > 0.

MachineVerifier: Verify REG_SEQUENCE

Somehow there was no verification of this, other than an ad-hoc
assertion in TwoAddressInstructions.

[MachineVerifier] Fix crash on early clobbered subreg operands.

MachineVerifier tried to checkLivenessAtDef() ignoring it is actually a subreg.

The issue was with processing two subregs of the same

[MachineVerifier] Fix crash on early clobbered subreg operands.

MachineVerifier tried to checkLivenessAtDef() ignoring it is actually a subreg.

The issue was with processing two subregs of the same reg are used in the same
instruction (e.g. inline asm): "def early-clobber" and other just "def".

Reviewed By: foad

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

show more ...

[MachineVerifier] add checks for INLINEASM_BR

Test for a case we observed after the initial implementation of D129997
landed, in which case we observed a crash while building the ppc64le
Linux kerne

[MachineVerifier] add checks for INLINEASM_BR

Test for a case we observed after the initial implementation of D129997
landed, in which case we observed a crash while building the ppc64le
Linux kernel. In that case, we had one block with two exits, both to the
same successor. Removing one of the exits corrupted the
successor/predecessor lists.

So when we have an INLINEASM_BR, check a few things for each indirect
target:
1. that it exists.
2. that it is listed in our successors.
3. that its predecessor list contains the parent MBB of INLINEASM_BR.

This would have caught the regression discovered after D129997 landed,
after the pass that was problematic (early-tailduplication) rather than
getting a stack trace in a later pass (regalloc) that doesn't understand
the anomaly and crashes.

Reviewed By: efriedma

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

show more ...

Untangle the mess which is MachineBasicBlock::hasAddressTaken().

There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to

Untangle the mess which is MachineBasicBlock::hasAddressTaken().

There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to map the
IR-level value to some specific block of machine code. Or there can be
constructs inside a function which involve using the address of a basic
block to implement certain kinds of control flow.

Mixing these together causes a problem: if target-specific passes are
marking random blocks "address-taken", if we have a BlockAddress, we
can't actually tell which MachineBasicBlock corresponds to the
BlockAddress.

So split this into two separate bits: one for BlockAddress, and one for
the machine-specific bits.

Discovered while trying to sort out related stuff on D102817.

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

show more ...

[CodeGen] Qualify auto variables in for loops (NFC)