This iterator range just includes physical registers and register masks,
which are interesting when dealing with register liveness.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/LivePhysRegs.cpp | ||
---|---|---|
47 | In this patch, we don't have an equivalent check to O->isDebug(). Instead, all we have is a check for MOP.isDef(). Do we need a similar check in the new code? |
llvm/lib/CodeGen/LivePhysRegs.cpp | ||
---|---|---|
47 | Yep, I originally thought that Debug operands cannot also be physical registers, but given that all the existing places check for it I guess its safer to explicitly filter them out. I've update the patch ( and also added a comment to phys_regs_and_masks) |
Build result: pass - 60637 tests passed, 0 failed and 726 were skipped.
Log files: console-log.txt, CMakeCache.txt
Hi Florian,
I have encountered a big compile time regression in the machine outlining caused by https://reviews.llvm.org/D70562.
After I backed out the change in D70562, the compile time for the three apps below was back.
I believe the reason is due to the introduction of function phys_regs_and_masks as below. Originally there is only one loop. With this change, it becomes two loops since it collects the legal operands first. If the filter does not have any effect, it essentially means the loop trip count is doubled.
for (ConstMIBundleOperands O(MI); O.isValid(); ++O) {
>
for (const MachineOperand &MOP : phys_regs_and_masks(MI)) {
When I back out the change D70562, I have also made minor changes in file llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp since phys_regs_and_masks is used in that file.
app1 app2 app3
Build Time (LLVM 9.0) 4278.512s 2547.800s 5917.305s
Build Time (LLVM 10.0) 5625.795s 4254.092s 9474.335s
Build Time (LLVM 10.0 + backout D70562) 4757.243s (+15%) 2618.070s (+42%) 6996.272s (+26%)
Let me take a look. Are the apps accessible somewhere? Or could be you provide a MIR/bitcode file to reproduce?
In this patch, we don't have an equivalent check to O->isDebug(). Instead, all we have is a check for MOP.isDef().
Do we need a similar check in the new code?