[PATCH] D41226: LiveDebugValues spill recognition expasnsion
Bjorn Pettersson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Jan 6 18:22:35 PST 2018
bjope added a comment.
I do not quite get it why the case when the register is killed in the subsequent instructions is so interesting.
Is this some kind of heuristic just to cover one specific scenario (then I think the summary, and future commit message should mention that, and also add some code comments describing what is going on here).
I mean, what makes this situation with a kill in the subsequent instruction different from a situation when there is one or more instructions in between, such as
A: spills register x
B: an MI not using or defining x
C: last use of x (kill x)
With you solution the result would differ depending on how instruction B and C are scheduled. That seems a little bit hacky to me, and it would at least be worth mentioning that the solution is some kind of heuristic (or that there is a technical debt left).
Comment at: lib/CodeGen/LiveDebugValues.cpp:451
+ // previous spill instruction that is killed in NextI.
+ if (getRegIfKilled(MONext, RegNext) && RegNext == Reg)
+ return true;
Isn't it still weird to use Reg here. The getRegIfKilled call on line 439 can return false without setting Reg (due to the operand not being a use, or not even being a register).
Comment at: test/DebugInfo/MIR/X86/kill-after-spill.mir:13
+# A - possible spill instruction with register R2
+# B - instructio that kills R3
More information about the llvm-commits