[PATCH] D38128: Handle COPYs of physregs better (regalloc hints)

Jonas Paulsson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 24 06:45:27 PDT 2017


jonpa added a comment.

In https://reviews.llvm.org/D38128#905052, @uweigand wrote:

> In https://reviews.llvm.org/D38128#904899, @jonpa wrote:
>
> > Would any of these be an improvement worth trying, then?
> >
> > (1) If the source phys-reg is contained in the regclass of an immediately following instruction using the vreg, then increase the priority of the hint of that phys-reg.
> >  (2) A simpler alternative would be to simply prefer phys-reg sources more than phys-reg dest-regs (if weight is equal). That would catch all the cases of (1).
>
>
> I believe (2) makes sense ...  certainly worth a try.


I see that on SPEC/z13, I now get a few more copys left. Compared to master:

  lgr            :               341784               328956   -12828
  lr             :                26208                25803     -405
  ...
  Spill|Reload   :               165135               164761     -374

-> with prefer phys reg source COPYs:

  lgr            :               341784               329060   -12724
  lr             :                26208                25817     -391
  ...
  Spill|Reload   :               165135               164934     -201

I also see looking at just the loops that while 120 innner loops have changed size, 103 of them has gotten
bigger, which seems to indicate that at least currently (Wei Mi has an upcoming regsplit patch that may
change this), this idea is not quite promising.

It did however handle the test case under discussion (ARM/swifterror.ll)

Reversing this heuristic so that phys-reg dest copys are prioritized:

  lgr            :               341784               328907   -12877
  lr             :                26208                25762     -446
  ...
  Spill|Reload   :               165135               164807     -328

For the innermost loops, there are only 34 different (15 smaller).

I am not sure it is right to tamper with this in this way given the above...


https://reviews.llvm.org/D38128





More information about the llvm-commits mailing list