> 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