[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