#
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 ...
|