[PATCH] D22718: MachineFunction: Remove AllVRegsAllocated property

Matthias Braun via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 25 13:43:01 PDT 2016


MatzeB added a comment.

In https://reviews.llvm.org/D22718#495247, @kparzysz wrote:

> In https://reviews.llvm.org/D22718#495216, @MatzeB wrote:
>
> > On the other hand I would find it very troubling if "AllVRegsAllocated" would just have an abstract meaning of a pass that runs after the register allocator. Why would is be important to run a certain place in the pass pipeline?
>
>
> For a pass, yes, altough there are passes that can run in both scenarios (MachineLICM, IIRC).  What I was thinking about were utility routines that can be called at various times.  In our internal Hexagon repo we have to maintain super-register liveness via implicit operands.  We have a function that updates those and it's called from places like, for example, loadRegFromStackSlot.  This function does not know where in the optimization pipleline it was called from.  Checking whether the destination register is physical or virtual is not sufficient, because we really only want to do this after RA has completed.  Once we get the subregister liveness tracking enabled, this problem will go away, but in general it shows that there can be cases whether the pre- vs post-RA status may be useful to know.


I think if you look think about .mir files the it becomes clear why an attribute on a machine function is strange:

  file1.mir:
  ...
  name: foo
  AllVRegsAllocated: true
  body: |
    bb.0:
      RETQ
  ---



  file2.mir
  ...
  name: foo
  AllVRegsAllocated: false
  body: |
    bb.0:
      RETQ
  ---

Today those are two different functions, but why is that difference meaningful? Also typing the "AllVRegsAllocated: " seems unnecessary.


Repository:
  rL LLVM

https://reviews.llvm.org/D22718





More information about the llvm-commits mailing list