[SDAG] Fix release build

This variable was only declared in debug builds, but is needed
in release builds as well.

[Verifier] Make Verifier recognize undef tokens as correct IR

Undef tokens may appear in unreached code as result of RAUW of some optimization,
and it should not be considered as bad IR.

Patch by D

[Verifier] Make Verifier recognize undef tokens as correct IR

Undef tokens may appear in unreached code as result of RAUW of some optimization,
and it should not be considered as bad IR.

Patch by Dmitry Bakunevich!

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

show more ...

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

[llvm] Use value instead of getValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

[llvm] Use value_or instead of getValueOr (NFC)

[StatepointLowering] Properly handle local and non-local relocates of the same value.

FunctionLoweringInfo::StatepointRelocationMaps map is used to pass GC pointer
lowering information from statepoi

[StatepointLowering] Properly handle local and non-local relocates of the same value.

FunctionLoweringInfo::StatepointRelocationMaps map is used to pass GC pointer
lowering information from statepoint to gc.relocate which may appear ini
different block.
D124444 introduced different lowering for local and non-local relocates.
Local relocates use SDValue and non-local relocates use value exported to VReg.
But I overlooked the fact that StatepointRelocationMap is indexed not by
GCRelocate instruction, but by derived pointer. This works incorrectly when
we have two relocates (one local and another non-local) of the same value,
because they need different relocation records.

This patch fixes the problem by recording relocation information per relocate
instruction, not per derived pointer. This way, each gc.relocate can be lowered
differently.

Reviewed By: skatkov

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

show more ...

[StatepointLowering] Only export STATEPOINT results if used in nonlocal blocks.

Cuurently we always export STATEPOINT results (GC pointers lowered via VRegs)
to virtual registers. When processing gc

[StatepointLowering] Only export STATEPOINT results if used in nonlocal blocks.

Cuurently we always export STATEPOINT results (GC pointers lowered via VRegs)
to virtual registers. When processing gc.relocate instructions we have to
generate CopyFromRegs node and then export it to VReg again if gc.relocate
is used in other basic blocks. This results in generation of extra COPY MIR
instruction if statepoint and its gc.relocate are in the same BB, but gc.relocate
result is used in other blocks.

This patch changes this behavior to export statepoint results only if used
in other basic blocks. For local uses StatepointLoweringState.(get|set)Location()
API is used to communicate appropriate statepoint result from `LowerStatepoint()`
to `visitGCRelocate()`

This is NFC and is purely compile time optimization. On big methids it can improve
codegen compile time up to 10%.

Reviewed By: reames

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

show more ...

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

[Statepoint] Remove another use of getActualReturnType [NFC]

For the cross block gc.result projection case, we only care about the return type if there is a cross block gc.result, and if there is on

[Statepoint] Remove another use of getActualReturnType [NFC]

For the cross block gc.result projection case, we only care about the return type if there is a cross block gc.result, and if there is one, we can take the type from the gc.result.

At the moment, this makes little difference, but for opaque pointers we need a means to get result typing without relying on pointee types.

show more ...

[Statepoints] Take result type from gc.result [NFC]

When lowering a gc.result, we can assume that the result type of the gc.result matches the type of the underlying call. This is explicitly requir

[Statepoints] Take result type from gc.result [NFC]

When lowering a gc.result, we can assume that the result type of the gc.result matches the type of the underlying call. This is explicitly required in LangRef.

At the moment, this makes little difference, but for opaque pointers we need a means to get result typing without relying on pointee types.

show more ...

Sink getGCResultLocality to sole use [NFC]

[Analysis, CodeGen] Migrate from arg_operands to args (NFC)

Note that arg_operands is considered a legacy name. See
llvm/include/llvm/IR/InstrTypes.h for details.

[Statepoint Lowering] Cleanup: remove unused option statepoint-always-spill-base.

[GC][NFC] Move GCStrategy from CodeGen to IR

We want it to be available in analyzes so that we could use the
CodeGen notion in middle-end passes (for example, to check if
a GC may free some particul

[GC][NFC] Move GCStrategy from CodeGen to IR

We want it to be available in analyzes so that we could use the
CodeGen notion in middle-end passes (for example, to check if
a GC may free some particular pointer).

This is a preparatory patch that simply moves the files around.

Note: if this causes some build issues, this patch must just be reverted.

Differential Revision: https://reviews.llvm.org/D100557
Reviewed By: reames

show more ...

[Statepoint Lowering] Allow other than N byte sized types in deopt bundle

I do not see any bit-width restriction from the point of the
LLVM Lang Ref - Operand Bundles on the types of the deopt bundl

[Statepoint Lowering] Allow other than N byte sized types in deopt bundle

I do not see any bit-width restriction from the point of the
LLVM Lang Ref - Operand Bundles on the types of the deopt bundle
operands. Statepoint Lowering seems to be able to work with any
types.
This patch relaxes the two related assertions and adds a new test
for this change.

Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D100006

show more ...

[Statepoint Lowering] Handle the case with several gc.result

Recently gc.result has been marked with readnone instead of readonly and
this opens a door for different optimization to duplicate gc.res

[Statepoint Lowering] Handle the case with several gc.result

Recently gc.result has been marked with readnone instead of readonly and
this opens a door for different optimization to duplicate gc.result.
Statepoint lowering is not ready to see several gc.results.
The problem appears when there are gc.results with one located in the same
basic block and another located in other basic block.
In this case we need both export VR and fill local setValue.

Note that this case is not sufficient optimization done before CodeGen.
It is evident that local gc.result dominates all other gc.results and it is handled
by GVN and EarlyCSE.

But anyway, even if IR is not optimal Backend should not crash on a valid IR.

Reviewers: reames, dantrushin
Reviewed By: dantrushin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D98393

show more ...

[Statepoint Lowering] Fix the crash with gc.relocate in a separate block

If it was decided to relocate derived pointer using the spill its value is
not exported in general case.
When gc.relocate is

[Statepoint Lowering] Fix the crash with gc.relocate in a separate block

If it was decided to relocate derived pointer using the spill its value is
not exported in general case.
When gc.relocate is located in an another block than a statepoint we cannot
get SD for derived value but for spill case it is not required at all.
However implementation of gc.relocate lowering unconditionally request SD value
causing the assert triggering.

The CL fixes this by handling spill case earlier than SD is really required.

Reviewers: reames, dantrushin
Reviewed By: dantrushin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D98324

show more ...

[Statepoint Lowering] Consider dead deopt gc values together with other gc values

Currently dead gc value mentioned in the deopt section are not listed in gc section
and so are processed separately.

[Statepoint Lowering] Consider dead deopt gc values together with other gc values

Currently dead gc value mentioned in the deopt section are not listed in gc section
and so are processed separately.
With this CL all deopt gc values are considered as base pointers and processed in the
same way as other gc values.

The fact that deopt gc pointer is a base pointer was used all the time but
it is explicitly documented here by putting the value in SI.Base.

The idea of the patch comes from Philip Reames.

Reviewers: reames, dantrushin
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D97554

show more ...

[Statepoint lowering] Require spill of deopt value in case its type is not legal

If the type of the deopt operand has an illegal type and we want to use
register for it then it needs to be legalized

[Statepoint lowering] Require spill of deopt value in case its type is not legal

If the type of the deopt operand has an illegal type and we want to use
register for it then it needs to be legalized.
This is not supported currently by legalizer and it is not actually clear how to
legalize this type of values.

Instead we just spill such values and use spill slot location in statepoint.

Originally tests were created by Philip Reames.

Reviewers: reames, dantrushin
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D97541

show more ...

[Statepoint Lowering] Add an option to allow use gc values in regs for landing pad

Default value is not changed, so it is NFC actually.

The option allows to use gc values on registers in landing pa

[Statepoint Lowering] Add an option to allow use gc values in regs for landing pad

Default value is not changed, so it is NFC actually.

The option allows to use gc values on registers in landing pads.

Reviewers: reames, dantrushin
Reviewed By: reames, dantrushin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D94469

show more ...

[CodeGen] Use llvm::append_range (NFC)