Re: [PATCH v2 0/9] Separate shrink-wrapping

[Jeff Law <law@redhat.com>]

On 09/09/2016 12:19 AM, Segher Boessenkool wrote:
> Thanks for looking at the patches Jeff.
>
> On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote:
>> Right.  Essentially Segher's patch introduces the concept of prologue
>> components that are independent of each other and which can be
>> shrink-wrapped separately.  The degree of independence is highly target
>> specific, of course.
>
> There can be dependencies as well (e.g. a save to the frame requires that
> frame to be set up already), but the current patches have no way to
> describe such dependencies.  I haven't found a good way to describe the
> dependencies yet.  Finding a good balance between general and useful isn't
> easy, as usual.
Right.  I over-simplified a bit here.  Some dependencies can be handled 
via the hooks in the target files.  I think what we've got is sufficient 
for now -- we'll have a much clearer picture of weak spots in the design 
if/when someone enables separate shrink wrapping for another target. 
Until then, I think we're OK.

>
>> I think one of the questions (and I haven't looked through the whole
>> thread yet to see if it's answered) is why the basic shrink-wrapping
>> algorithm can't be applied to each of the prologue components -- though
>> you may have answered it with your loop example below.
>
> You get code size explosion with the "basic" algorithm.  And a lot of
> that isn't really worth it: avoiding the whole prologue/epilogue is
> usually worth copying some blocks for, but avoiding just a single register
> save/restore pair?  More doubtful.
Understood.   We have similar balancing problems elsewhere.  How much 
duplication should we allow to expose a CSE or eliminate a conditional 
jump on a path through the CFG.

So I think sticking with this as a design decision makes sense -- does 
it impact the issue around running a particular component's prologue 
more than once?


>> Thanks.  I'd been wondering about when it'd be useful to push prologue
>> code into a loop nest when I saw the patches fly by, but didn't think
>> about it too much.  I haven't looked at the shrink-wrapping literature
>> in years, but I don't recall it having any concept that there were cases
>> where sinking into a loop nest was profitable.
>
> It isn't common, but it does happen.  If you use a proper cost metric
> based on executiuon frequency with some algorithm then that algorithm will
> naturally avoid placing *logues into loops.
Right and the cases where it's placing them into loops it's going to be 
doing so on paths that are unlikely executed within the loop.  ISTM that 
using frequencies is a significant step forward over the older placement 
algorithms in this space (which IIRC were structured as simple dataflow 
solvers) -- with the added advantage that if we have profiling data we 
can make better decisions.

Does this impact the compile time computation complexity issue that was 
raised elsewhere?

jeff