Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate components

[Jeff Law <law@redhat.com>]

On 09/14/2016 07:38 AM, Segher Boessenkool wrote:
> On Mon, Sep 12, 2016 at 12:02:50PM -0600, Jeff Law wrote:
>>>>> As a final optimisation, if a block needs a prologue and its immediate
>>>>> dominator has the block as a post-dominator, the dominator gets the
>>>>> prologue as well.
>>>> So why not just put it in the idom and not in the dominated block?
>>>
>>> That's what it does :-)
>> Then I must have mis-parsed.  Thanks for clarifying.
>
> "As a final optimisation, if a block needs a prologue and its immediate
> dominator has the block as a post-dominator, ***that immediate dominator***
> gets the prologue as well."
>
> That is clearer I hope :-)
It is :-)

>
>> Hmm, then explain again why DCE is mucking up?  I don't immediately see
>> how EPILOGUE_BEG notes come into play with DCE.  It seems to rely on the
>> DF data and AFAICT DF only cares about the EPILOGUE_BEG note in
>> can_move_insns_across which shouldn't be used by DCE.
>
> The register restore *is* dead code, but we need to have the same CFI
> for all convergent paths.
OK.   I think I was conflating multiple issues.  So we need to keep the 
restore alive so that we have the same CFI across those paths, even 
though it appears dead on one or more paths.

I think this points us back to what you were experimenting with to 
address the regrename problems -- specifically creating "uses" at those 
key points.  That solves the DCE problem as well as one of the regrename 
problems, right?

>>
>> Whether or not an edge needs a prologue or epilogue is a function not
>> just of the state at the head or tail of the edge, but instead is a
>> function of global dataflow propagation?  Thus we can't disqualify until
>> after we've done the dataflow propagation?  Right?
>
> We can figure out before we decide what blocks need what components, what
> edges can not get a prologue or epilogue for which components.  This
> complicates the selection algorithm a whole lot, for not much gain that
> I have seen so far, so I just give up in the cases that end up "bad".
OK.  I'll drop it :-)  It was more a mental exercise in understanding 
then something I think needed to change.

Jeff