> On Sep 10, 2020, at 5:05 PM, Segher Boessenkool <seg...@kernel.crashing.org> 
> wrote:
> 
> On Tue, Sep 08, 2020 at 11:43:30AM -0500, Qing Zhao wrote:
>>> On Sep 7, 2020, at 10:58 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Mon, Sep 7, 2020 at 7:06 AM Segher Boessenkool
>>> <seg...@kernel.crashing.org <mailto:seg...@kernel.crashing.org>> wrote:
>>>> On Fri, Sep 04, 2020 at 11:52:13AM -0700, H.J. Lu wrote:
>>>>> On Fri, Sep 4, 2020 at 11:09 AM Segher Boessenkool
>>>>> <seg...@kernel.crashing.org> wrote:
>>>>>> Very many normal returns do *not* pass through an epilogue, but are
>>>>>> simple_return.  Disabling that is *much* more expensive than that 2%.
>>>>> 
>>>>> Sibcall isn't covered.  What other cases don't have an epilogue?
>>>> 
>>>> Shrink-wrapped stuff.  Quite important for performance.  Not something
>>>> you can throw away.
>>> 
>>> Qing, can you check how it interacts with shrink-wrap?
>>>> 
> 
> <snip>
> 
>> But I might miss some important  issues here, please let me know what I am 
>> missing here?
> 
> Start looking at handle_simple_exit()?  targetm.gen_simple_return()…

Yes, I have been looking at this since this morning. 
You are right, we also need to insert zeroing sequence before  this 
simple_return which the current patch missed.

I am currently try to resolve this issue with the following idea:

In the routine “thread_prologue_and_epilogue_insns”,  After both 
“make_epilogue_seq” and “try_shrink_wrapping” finished, 

Scan every exit block to see whether the last insn is a ANY_RETURN_P(insn), 
If YES, generate the zero sequence before this RETURN insn. 

Then we should take care all the exit path that returns.

Do you see any issue from this idea? 

Thanks a lot for your help.

Qing

> 
> 
> Segher

Reply via email to