History log of /llvm-project/llvm/lib/CodeGen/MachineFunction.cpp (Results 51 – 75 of 588)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 9e6d1f4b 17-Jul-2022 Kazu Hirata <kazu@google.com>

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


# 90f96ec7 17-Jun-2022 Guillaume Chatelet <gchatelet@google.com>

[NFC][Alignment] Remove assumeAligned from MachineFrameInfo ctor


# a2232da2 14-Jun-2022 Kazu Hirata <kazu@google.com>

[CodeGen] Remove addSEHCatchHandler and addSEHCleanupHandler (NFC)

The last uses of these functions are removed on Oct 9, 2015 in commit
14e773500e036de57ed0ca4af6fddc1f8b6767d8.


# 0e1c71e4 27-Apr-2022 Matt Arsenault <Matthew.Arsenault@amd.com>

CodeGen: Move getAddressSpaceForPseudoSourceKind into TargetMachine

Avoid the dependency on TargetInstrInfo, which depends on the subtarget
and therefore the individual function.

Currently AMDGPU i

CodeGen: Move getAddressSpaceForPseudoSourceKind into TargetMachine

Avoid the dependency on TargetInstrInfo, which depends on the subtarget
and therefore the individual function.

Currently AMDGPU is constructing PseudoSourceValue instances in MachineFunctionInfo.
In order to facilitate copying MachineFunctionInfo, we need to stop allocating these
there. Alternatively we could allow targets to subclass PseudoSourceValueManager,
and allocate them similarly to MachineFunctionInfo.

show more ...


# 1d712c38 03-May-2022 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][InstrRef] Don't generate redundant DBG_PHIs

In SelectionDAG, DBG_PHI instructions are created to "read" physreg values
and give them an instruction number, when they can't be traced back

[DebugInfo][InstrRef] Don't generate redundant DBG_PHIs

In SelectionDAG, DBG_PHI instructions are created to "read" physreg values
and give them an instruction number, when they can't be traced back to a
defining instruction. The most common scenario if arguments to a function.
Unfortunately, if you have 100 inlined methods, each of which has the same
"this" pointer, then the 100 dbg.value instructions become 100
DBG_INSTR_REFs plus 100 DBG_PHIs, where only one DBG_PHI would suffice.

This patch adds a vreg cache for MachienFunction::salvageCopySSA, if we've
already traced a value back to the start of a block and created a DBG_PHI
then it allows us to re-use the DBG_PHI, as well as reducing work.

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

show more ...


# 61e36e87 19-Apr-2022 Paul Kirth <paulkirth@google.com>

[safestack] Support safestack in stack size diagnostics

Current stack size diagnostics ignore the size of the unsafe stack.
This patch attaches the size of the static portion of the unsafe stack
to

[safestack] Support safestack in stack size diagnostics

Current stack size diagnostics ignore the size of the unsafe stack.
This patch attaches the size of the static portion of the unsafe stack
to the function as metadata, which can be used by the backend to emit
diagnostics regarding stack usage.

Reviewed By: phosek, mcgrathr

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

show more ...


# fb6596f1 06-Apr-2022 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][InstrRef] Avoid a crash from mixed variable location modes

Variable locations now come in two modes, instruction referencing and
DBG_VALUE. At -O0 we pick DBG_VALUE to allow fast constru

[DebugInfo][InstrRef] Avoid a crash from mixed variable location modes

Variable locations now come in two modes, instruction referencing and
DBG_VALUE. At -O0 we pick DBG_VALUE to allow fast construction of variable
information. Unfortunately, SelectionDAG edits the optimisation level in
the presence of opt-bisect-limit, meaning different passes have different
views of what variable location mode we should use. That causes assertions
when they're mixed.

This patch plumbs through a boolean in SelectionDAG from start to
instruction emission, so that we don't rely on the current optimisation
level for correctness.

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

show more ...


# 989f1c72 15-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

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

show more ...


# a278250b 10-Mar-2022 Nico Weber <thakis@chromium.org>

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...


# 7f230fee 07-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup codegen includes

after: 1061034926
before: 1063332844

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


# 0e96d95d 04-Mar-2022 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][InstrRef] Accept register-reads after isel in any block

When lowering LLVM-IR to instruction referencing stuff, if a value is
defined by a COPY, we try and follow the register definition

[DebugInfo][InstrRef] Accept register-reads after isel in any block

When lowering LLVM-IR to instruction referencing stuff, if a value is
defined by a COPY, we try and follow the register definitions back to where
the value was defined, and build an instruction reference to that
instruction. In a few scenarios (such as arguments), this isn't possible.
I added some assertions to catch cases that weren't explicitly whitelisted.

Over the course of a few months, several more scenarios have cropped up,
the lastest is the llvm.read_register intrinsic, which lets LLVM-IR read an
arbitary register at any point. In the face of this, there's little point
in validating whether debug-info reads a register in an expected scenario.
Thus: this patch just deletes those assertions, and adds a regression test
to check that something is done with the llvm.read_register intrinsic.

Fixes #54190

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

show more ...


# 6a605b97 12-Jan-2022 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo] Move flag for instr-ref to LLVM option, from TargetOptions

This feature was previously controlled by a TargetOptions flag, and I
figured that codegen::InitTargetOptionsFromCodeGenFlags w

[DebugInfo] Move flag for instr-ref to LLVM option, from TargetOptions

This feature was previously controlled by a TargetOptions flag, and I
figured that codegen::InitTargetOptionsFromCodeGenFlags would default it
to "on" for all frontends. Enabling by default was discussed here:

https://lists.llvm.org/pipermail/llvm-dev/2021-November/153653.html

and originally supposed to happen in 3c045070882f3, but it didn't actually
take effect, as it turns out frontends initialize TargetOptions themselves.
This patch moves the flag from a TargetOptions flag to a global flag to
CodeGen, where it isn't immediately affected by the frontend being used.
Hopefully this will actually cause instr-ref to be on by default on x86_64
now!

This patch is easily reverted, and chances of turbulence are moderately
high. If you need to revert, please consider instead commenting out the
'return true' part of llvm::debuginfoShouldUseDebugInstrRef to turn the
feature off, and dropping me an email.

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

show more ...


# bb6447a7 13-Dec-2021 Kazu Hirata <kazu@google.com>

[llvm] Use llvm::reverse (NFC)


# 4afae6f7 09-Dec-2021 Mircea Trofin <mtrofin@google.com>

[NFC] Rename MachineFunction::cloneMachineInstrBundle (coding style)


# b0127424 09-Dec-2021 Mircea Trofin <mtrofin@google.com>

[NFC] Rename MachineFunction::deleteMachineInstr (coding style)


# 91a0da01 09-Dec-2021 Mircea Trofin <mtrofin@google.com>

[NFC] Rename MachineFunction::DeleteMachineBasicBlock

Renamed to conform to coding style


# 2bd7384d 07-Dec-2021 Mircea Trofin <mtrofin@google.com>

[NFC][MachineInstr] Pass-by-value DebugLoc in CreateMachineInstr

DebugLoc is cheap to move, passing it by-val rather than const ref to
take advantage of the fact that it is consumed that way by the

[NFC][MachineInstr] Pass-by-value DebugLoc in CreateMachineInstr

DebugLoc is cheap to move, passing it by-val rather than const ref to
take advantage of the fact that it is consumed that way by the
MachineInstr ctor, which creates some optimization oportunities.

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

show more ...


# f108c7f5 05-Dec-2021 Jack Andersen <jackoalan@gmail.com>

[GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.

Expanding on D109750.

Since `DBG_VALUE` instructions have final register validity determined in
`LDVImpl::handleDebugValu

[GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.

Expanding on D109750.

Since `DBG_VALUE` instructions have final register validity determined in
`LDVImpl::handleDebugValue`, there is no apparent reason to immediately prune
unused register operands as their defs are erased. Consequently, this renders
`MachineInstr::eraseFromParentAndMarkDBGValuesForRemoval` moot; gaining a
substantial performance improvement.

The only necessary changes involve making relevant passes consider invalid
DBG_VALUE vregs uses as valid.

Reviewed By: MatzeB

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

show more ...


# ca2f5389 04-Dec-2021 Kazu Hirata <kazu@google.com>

[CodeGen] Use range-based for loops (NFC)


# b8f68ad9 24-Nov-2021 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][InstrRef] Avoid crash when values optimised out late in sdag

It appears that we can emit all the instructions for a function, including
debug instructions, and then optimise some of the

[DebugInfo][InstrRef] Avoid crash when values optimised out late in sdag

It appears that we can emit all the instructions for a function, including
debug instructions, and then optimise some of the values out late.
Specifically, in the attached test case, an argument gets optimised out
after DBG_VALUE / DBG_INSTR_REFs are created. This confuses
MachineFunction::finalizeDebugInstrRefs, which expects to be able to find a
defining instruction, and crashes instead.

Fix this by identifying when there's no defining instruction, and
translating that instead into a DBG_VALUE $noreg.

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

show more ...


# d5b73a70 23-Nov-2021 Kazu Hirata <kazu@google.com>

[llvm] Use range-based for loops (NFC)


# 73797367 14-Nov-2021 Kazu Hirata <kazu@google.com>

[llvm] Use range-based for loops with User::operands (NFC)


# ee3eee71 25-Oct-2021 Jeremy Morse <jeremy.morse@sony.com>

[DebugInfo][InstrRef] Track values fused into stack spills

During register allocation, some instructions can have stack spills fused
into them. It means that when vregs are allocated on the stack we

[DebugInfo][InstrRef] Track values fused into stack spills

During register allocation, some instructions can have stack spills fused
into them. It means that when vregs are allocated on the stack we can
convert:

SETCCr %0
DBG_VALUE %0

to

SETCCm %stack.0
DBG_VALUE %stack.0

Unfortunately instruction referencing finds this harder: a store to the
stack doesn't have a specific operand number, therefore we don't substitute
the old operand for a new operand, and the location is dropped. This patch
implements a solution: just recognise the memory operand attached to an
instruction with a Special Number (TM), and record a substitution between
the old value and the new one.

This patch adds substitution code to InlineSpiller to record such fused
spills, and tracking in InstrRefBasedLDV to recognise such values, and
produce the value numbers for them. Everything to do with the movement of
stack-defined values is already handled in InstrRefBasedLDV.

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

show more ...


# 36deb9a6 15-Oct-2021 Jay Foad <jay.foad@amd.com>

Add new MachineFunction property FailsVerification

TargetPassConfig::addPass takes a "bool verifyAfter" argument which lets
you skip machine verification after a particular pass. Unfortunately
this

Add new MachineFunction property FailsVerification

TargetPassConfig::addPass takes a "bool verifyAfter" argument which lets
you skip machine verification after a particular pass. Unfortunately
this is used in generic code in TargetPassConfig itself to skip
verification after a generic pass, only because some previous target-
specific pass damaged the MIR on that specific target. This is bad
because problems in one target cause lack of verification for all
targets.

This patch replaces that mechanism with a new MachineFunction property
called "FailsVerification" which can be set by (usually target-specific)
passes that are known to introduce problems. Later passes can reset it
again if they are known to clean up the previous problems.

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

show more ...


# bd4dad87 07-Oct-2021 Jack Andersen <jackoalan@gmail.com>

[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand

Based on the reasoning of D53903, register operands of DBG_VALUE are
invariably treated as RegState::

[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand

Based on the reasoning of D53903, register operands of DBG_VALUE are
invariably treated as RegState::Debug operands. This change enforces
this invariant as part of MachineInstr::addOperand so that all passes
emit this flag consistently.

RegState::Debug is inconsistently set on DBG_VALUE registers throughout
LLVM. This runs the risk of a filtering iterator like
MachineRegisterInfo::reg_nodbg_iterator to process these operands
erroneously when not parsed from MIR sources.

This issue was observed in the development of the llvm-mos fork which
adds a backend that relies on physical register operands much more than
existing targets. Physical RegUnit 0 has the same numeric encoding as
$noreg (indicating an undef for DBG_VALUE). Allowing debug operands into
the machine scheduler correlates $noreg with RegUnit 0 (i.e. a collision
of register numbers with different zero semantics). Eventually, this
causes an assert where DBG_VALUE instructions are prohibited from
participating in live register ranges.

Reviewed By: MatzeB, StephenTozer

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

show more ...


12345678910>>...24