[PATCH] D35816: [Greedy RegAlloc] Add logic to greedy reg alloc to avoid bad eviction chains

Wei Mi via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 25 11:41:51 PDT 2017


On Mon, Sep 25, 2017 at 10:44 AM, Quentin Colombet <qcolombet at apple.com>
wrote:

>
> > On Sep 25, 2017, at 8:46 AM, Marina Yatsina via Phabricator <
> reviews at reviews.llvm.org> wrote:
> >
> > myatsina added a comment.
> >
> > Hi Quentin,
> >
> > I wouldn’t say my patch tries to avoid splitting, but rather tries to
> improve the calculation of the spill weight of split candidates:
> > When the register allocator decides to do a region split, it looks for
> the best physical register candidate for the split.
> > The best candidate is the one that will cause the minimal spill cost.
> > When calculating the spill cost of each candidate the algorithm takes
> into account interferences in the entrance/exist of the basic blocks.
> > However, there may be interference local to a basic block, which later,
> during the split itself will cause the creation of a new local interval
> (which will be local to the basic block) on top of the “by reg” and “by
> stack” intervals which are created during the split.
> > The algorithm currently ignores the fact that this local interval may
> cause spills (and thus may increase the spill weight of this candidate for
> the split).
> >
> > My solution is to try to predict if this split candidate will case the
> creation of local intervals and if they in turn will cause spills, and add
> their spill weights to the total weight.
> > By doing so, I try to make the spill weight calculation of each
> candidate more accurate and allow the algorithm to choose a more suitable
> candidate.
> >
> > If a local interval is created then we have a few options for its
> allocation:
> >
> > 1. The interval will be allocated to some free reg – no additional spill
> cost needed.
> > 2. The interval may cause an eviction – in some cases this eviction is
> "bad" and guaranteed to causes a spill (it’s “bad” when you’re evicting the
> interval that evicted you, kind of like a cat and mouse game - somebody
> must loose here) - in this patch I’m trying to predict if it’s "bad" or
> not, and incorporate the spill weight of this interval.

> 3. The interval may spill – I’ve already encountered a case where the new
> local interval is in a hot loop and ends us spilling around all uses – this
> spill cost wasn’t considered when the candidate was chosen. I have a
> solution for this case which is based on parts of this patch.
>

For 3, it sounds like a separate problem from PR26810. Do you have a
testcase to show it?

Thanks,
Wei.


> > 4. The interval may split – I guess there might be some spill cost to
> consider here as well, but I didn’t explore this case yet.
> >
> > I did see nice performance results with my current solution.
>
> I can totally see that. I wonder if adding 1K LOC is worth it and in
> particular if we can’t have the same result with fewer LOC.
> My main concern is we try to predict yet another thing. Again the approach
> itself as you describe it makes sense, but the trade off complexity reward
> is not clear to me. In particular, what is the compile time impact, what
> are the regressions and so on.
>
> > I will try to look into the hint reconciling as well, but I do think
> that the current spill weight calculation of the split candidates is not
> accurate enough and we need to consider the affects of those local
> intervals.
> >
> > Thanks,
> > Marina
> >
> >
> > Repository:
> >  rL LLVM
> >
> > https://reviews.llvm.org/D35816
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170925/3ab31c15/attachment.html>


More information about the llvm-commits mailing list