[PATCH] Enhance loop rotation with existence of profile data in MachineBlockPlacement pass.

[Cong Hou]

On Mon, Jun 29, 2015 at 3:48 PM, Xinliang David Li <davidxl at google.com>
wrote:

> On Mon, Jun 29, 2015 at 11:39 AM, Cong Hou <congh at google.com> wrote:
> > On Mon, Jun 29, 2015 at 11:21 AM, Xinliang David Li <davidxl at google.com>
> > wrote:
> >>
> >> On Mon, Jun 29, 2015 at 11:03 AM, Cong Hou <congh at google.com> wrote:
> >> > In http://reviews.llvm.org/D10717#196064, @davidxl wrote:
> >> >
> >> >> Cong, the proposed cost analysis can not handle diamond shaped or
> loops
> >> >> with more complicated control flow. To handle those cases, I think
> you need
> >> >> to generalize it  by computing the complete branch costs for all
> rotation
> >> >> candidates and select the one with the least cost.  The entry and
> exit
> >> >> connection cost computation remains the same. To compute taken
> branch cost,
> >> >> there are only 4 cases to consider: tail BB with 1 successor, tail BB
> >> >> multiple successors, non-tail BB with 1 successor, non-tail BB with
> multiple
> >> >> successors.
> >> >>
> >> >> B0
> >> >>  do {
> >> >>
> >> >>   B1
> >> >>   if (..) {
> >> >>    B2
> >> >>   } else {
> >> >>    B3
> >> >>   }
> >> >>
> >> >> B4
> >> >>  } while (..);
> >> >>  B5;
> >> >>
> >> >> If the original layout keeps the topo order:
> >> >>  B0 B1 B2 B3 B4 B5
> >> >>
> >> >> The cost analysis should discover the optimal rotation to be
> >> >>  B0 B3 B4 B1 B2 B5
> >> >
> >> >
> >> > As we know, the current LLVM's algorithm always form a chain with all
> >> > BBs in a loop, which is a drawback. I will propose another patch that
> >> > changes this behavior. In the new algorithm, the loop chain formation
> may
> >> > stop as long as an exit is reached, and only this loop chain will be
> >> > rotated. This is similar to GCC's strategy. In the above example, once
> >> > B1->B3->B4 is formed, the loop chain build is complete. Then B1 is
> the best
> >> > candidate to be the chain bottom as there is an fall-thru edge from
> B1 to
> >> > B2.
> >>
> >>
> >> There two parts of the problem:
> >>
> >> 1) form the best base layout for the loop
> >> 2) find the best rotation strategy for the base layout.
> >>
> >> We are focusing on 2) here.  What I meant is that by enhancing your
> >> cost analysis using the scheme I mentioned, it is possible to find the
> >> best rotation even with the current base loop layout strategy (i.e.,
> >> forming a chain with all BBs) -- I manually verified the example
> >> quoted.
> >
> >
> > The patch here can handle the example proposed by you. We consider to
> rotate
> > the chain B1 B2 B3 B4, and the result B3 B4 B1 B2 is best. This is
> because
> > there is no edge from B2 to B3, so in our "benifit" analysis this won't
> > become a negative contribution to the benefit.
>
> True, but It is unclear whether it works by accident or by design?  We
> need to be able to prove that the current benefit analysis is good for
> arbitrary control flow in loop.
>
>
When rotating the loop, all impacts in terms of our cost model are
considered, so this patch should not hurt the performance if our cost model
is correct. In some cases, with the current LLVM's bb-layout algorithm,
rotating loop could not give us the best result: this is not the fault of
the loop rotation, but how we build chains for loops. In other words, in
the future if we improve the loop chain builds in LLVM, we can still use
the same loop rotation algorithm.



> A new test case like this one or other cases are useful in the patch too.
>

I will add a new test case with diamond CFG to this patch.


Cong



>
> David
>
>
>
> >
> >
> >>
> >>
> >> David
> >>
> >>
> >> >
> >> >
> >> > http://reviews.llvm.org/D10717
> >> >
> >> > EMAIL PREFERENCES
> >> >   http://reviews.llvm.org/settings/panel/emailpreferences/
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150629/553c8678/attachment.html>