[PATCH] D22718: MachineFunction: Remove AllVRegsAllocated property
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 8 17:53:51 PDT 2016
Hi Matthias,
I haven’t read all the discussion but I think I read enough to chime in.
I would like to keep the AllVRegsAllocated property.
I’m fine that the parser recomputes it based on the number of virtual registers, but I do not want it to be tight to that information dynamically. I believe part of the problem is in the naming of the property and the semantic attached to it.
This property means that:
1. No virtual registers are present (the dynamic check capture that)
2. Passes cannot introduce new VRegs (the name does not convey that, but the dynamic check would lose that information)
Regarding your example:
file1.mir:
...
name: foo
AllVRegsAllocated: true
body: |
bb.0:
RETQ
---
file2.mir
...
name: foo
AllVRegsAllocated: false
body: |
bb.0:
RETQ
—
This are semantically different in the sense that a pass working on that input could performance differently based on the value of the property. E.g., with AllVRegsAllocated == false, it could introduce vregs, whereas with AllVRegsAllocated == true, it would run the scavenger before exiting. If we make the property dynamic, the pass won’t see it has to scavenge the vregs it introduced.
Again, I believe this is a naming problem, but I don’t have a great naming, CanUseVRegs maybe?
Also, staying on that example, what would be the default value in that case?
Cheers,
-Quentin
> On Jul 25, 2016, at 1:53 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
>
> kparzysz added a comment.
>
> Yes, it is strange. Whether the RA has already run or not is not really a state of the function, I agree with that. I'm not opposed to this change, I'm just bringing up a potential consideration, that's all.
>
>
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D22718
>
>
>
More information about the llvm-commits
mailing list