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

Xinliang David Li davidxl at google.com
Mon Jun 29 17:14:07 PDT 2015


>> > 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.

yes -- that is what I'd like to hear but analytically prove it will be better :)

> 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.

yes, because only one dimension of the search space is explored.
Another dimension will be the base layout (e.g, considering splitting
etc).  My comment is not about your algorithm to find the optimal
rotation in this dimension (which is solid), but about where the 3
component cost function is sufficient.

David
>
>
>>
>> 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/
>> >> >
>> >> >
>> >
>> >
>
>



More information about the llvm-commits mailing list