- User Since
- Jun 5 2017, 7:59 AM (161 w, 5 d)
Nov 7 2018
Oct 21 2018
Now, I just wanted to point out that there are more opportunities to generalize the rematerialization. The obvious one to me is rematerializing everything (like pulling chain of computations, full instructions (with both definitions and arguments)) and in that sense, only the instruction or chain of instructions carry the right level of information. Right now we often introduce pseudo instruction to work around this limitation and that's what I would like to solve.
Oct 18 2018
I am not sure the enum approach is desirable as it basically hard code the kind of constraints we can report and will grow very quickly if we want to extend it.
For instance, let say that on top of physreg defs we want to report virtual reg defs, now we would need “yes”, “no”, “yes_phys”, “yes_virt”, “yes_phys_virt” and the list grows with the cross product of everything we may want/need to report.
Oct 17 2018
I think I have addressed all your previous concerns, @qcolombet, is there anything else you'd like to see clarified?
Sam Parker suggested I add you as a reviewer, @MatzeB, do you have any suggestions?
Oct 12 2018
Uses range based loop now.
Oct 9 2018
I have rebased onto the master branch at 244c796c894f50fb53f9dbe7627702661dfe69c2.
Rebased to current llvm master branch. Quentin, I have worked in your suggestion.
Jul 19 2017
Jul 17 2017
Jul 14 2017
Jul 13 2017
Thanks a lot Sam!