Re: [aarch64] disable shrink wrapping when tracking speculative execution

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

On 06/11/2018 18:18, Segher Boessenkool wrote:
> Hi Richard,
> 
> On Tue, Nov 06, 2018 at 11:46:53AM +0000, Richard Earnshaw (lists) wrote:
>> On 06/11/2018 01:40, Segher Boessenkool wrote:
>>> Hi Richard,
>>>
>>> On Mon, Nov 05, 2018 at 10:09:30AM +0000, Richard Earnshaw (lists) wrote:
>>>>>>> Shouldn't you be able to do this per function at least?
>>>>>>
>>>>>> do what per function?  track speculation?
>>>>>
>>>>> disable shrink-wrapping only when any speculation was there
>>>>> (this is about __bultin_speculation_safe_value, no?)
>>>>
>>>> Only indirectly.  This is about the tracking code that tracks
>>>> conditional branches and propagates that information through call/return
>>>> sequences.  Shrink wrapping messes with the prologue/epilogue sequences
>>>> after the speculation tracking pass has run and unknowingly deletes some
>>>> of the additional code that was previously inserted by the tracking pass.
>>>
>>> Do you have an example of this?  Shrink-wrapping does not generally
>>> delete any code.
>>>
>>
>> Well it generates new 'light-weight' prologue and epilogue sequences for
>> the 'shrunk' code path that lack the establishment of the tracker
>> register and doesn't know how to move the existing sequence to the new
>> entry sequence.
> 
> Ah, so the shrink-wrapping code is not deleting anything at all (just
> not adding it).  Gotcha :-)

Well.... you could argue that it deleted the tracker update for the case
where the branch was not taken, and it also deleted the part of the
prologue where the tracker state was restored into SP before the return.
 But I'm being picky... :-)

> 
> [ snip example code; thanks, that helped ]
> 
>> I'm not asking that shrink wrapping be updated to handle all this; in
>> fact, I'm not sure it's that easy to do as the branch patterns and
>> simple-return patterns aren't set up to handle this.
> 
> One thing you could do is make shrink-wrap aware what part of the code
> needs the speculation tracking parts of the prologue.  You could do this
> by making a separate shrink-wrapping component for it, or you can do it
> by marking the places needing it as needing the full prologue, e.g. by
> emitting a fake call into it (and not outputting any code for that call).
> The latter does cause a stack frame to be emitted even when it wouldn't
> otherwise, unfortunately.  The separate shrink-wrapping approach should
> work beautifully as far as I see.
> 
> 

There are number of optimizations that are worth investigation with the
tracking support; but whether they'll notably improve performance I'm
not sure.  Tracking just just expensive and the main problem is the
serialization of the state, which limits the core's ability to reorder
stuff internally.

R.