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

[Jeff Law <law@redhat.com>]

On 09/09/2016 09:17 AM, Segher Boessenkool wrote:
> On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
>> So can you expand on the malloc example a bit -- I'm pretty sure I
>> understand what you're trying to do, but a concrete example may help
>> Bernd and be useful for archival purposes.
>
> Sure, but it's big (which is the problem :-) )
Yea :(  But it's likely a very compelling example of real world code. 
It's almost certainly too big to turn into a testcase of any kind, but 
just some before/after annotated code would be helpful.

Ideally we'd have some smaller testcases we could put in the testsuite 
to ensure that the feature works over-time in the way intended would be 
helpful as well.

>>
>>>> That's a later addition anyway and isn't necessary to do
>>>> shrink-wrapping in the first place.
>>>
>>> No, it always did that, just not as often (it only duplicated straight-line
>>> code before).
>> Presumably (I haven't looked yet), the duplication is so that we can
>> isolate one or more paths which in turn allows sinking the prologue
>> further on some of those paths.
>
> It duplicates as many blocks as it needs to dup, to make as many exits
> as possible reachable without *any* prologue/epilogue.
>
> As the header comment before the older code says:
>
> /* Try to perform a kind of shrink-wrapping, making sure the
>    prologue/epilogue is emitted only around those parts of the
>    function that require it.
>
>    There will be exactly one prologue, and it will be executed either
>    zero or one time, on any path.
Right.  That's always been my understanding of the key driver for 
placement.  There's exactly one and will be executed one time or none 
across all paths in the CFG.

Essentially this is comparable to PRE-like algorithms for placement of 
expression evaluations.

And in separate shrink-wrapping world, we're leaving that model behind 
and I think that's one of the big things I'm struggling with -- we may 
execute a prologue component more than once if I've read everything 
correctly.


  Depending on where the prologue is
>    placed, some of the basic blocks can be reached via both paths with
>    and without a prologue.  Such blocks will be duplicated here, and the
>    edges changed to match.
Understood.

This really feels comparable to block duplication for the purposes of 
isolating a particular path through the CFG so that path can be modified 
without affecting the behavior of other paths through the CFG.

It's also directly comparable to block duplication to allow more 
aggressive code motion in PRE-like algorithms.

Jeff