Displaying 3 results from an estimated 3 matches for "endchang".
Did you mean:
endchar
2013 Feb 05
0
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
...nsider hoisting chained instructions out of a loop one at a time. The live ranges of the intermediate steps look completely different from the final result.
So for a future automatic liveness API, I imagine something like:
LIS.beginChanges();
..
Move multiple instructions around.
..
LIS.endChanges();
[Or it could use RAII, that's not important]
MachineFunction would provide observer hooks that LIS can use to collect a set of changed instructions. The call to LIS.endChanges() would then recompute the invalid live ranges.
/jakob
2013 Feb 04
2
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
Jakob,
Seems like an easy solution for this case... But let me ask you a more
general question.
The reason I kept on hanging on to the MBB->splice was (probably outdated)
assumption that it will one day properly update liveness for instructions it
moves... That is a serious matter for what I am trying to do (global code
motion in presence of bundles).
What is the current thinking? Will
2013 Feb 05
1
[LLVMdev] Asserts in bundleWithPred() and bundleWithSucc()
...use LIS does not work that late)... which is something I do not want to
carry forward for too long if I can avoid it.
In short, I do need a version of "move instruction" (or handleMove) that
would produce accurate global liveness after its use. If
LIS.beginChanges(); // change // LIS.endChanges();
will work as fast and efficiently, no problem then, but I have this feeling
that incremental liveness update (when possible) will be easier and cheaper
than full scan.
You have asked me before - when we are going to upstream the code that
does the global code motion - I can tell now that w...