> 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:
>>>> On Fri, Sep 04, 2020 at 10:34:23AM -0700, H.J. Lu wrote:
>>>>>> You probably have to do this for every target separately? But it is not
>>>>>> enough to handle it in the epilogue, you also need to make sure it is
>>>>>> done on every path that returns *without* epilogue.
>>>>>
>>>>> This feature is designed for normal return with epilogue.
>>>>
>>>> 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?
We have some discussion on shrink-wrapping previously. And we agreed on the
following at that time:
"Shrink-wrapping often deals with the non-volatile registers, so that
doesn't matter much for this patch series.”
On the other hand, we deal with volatile registers in this patch, so from the
registers point of view, there is NO overlap between this
Patch and the shrink-wrapping.
So, what’s the other possible issues when this patch interacting with
shrink-wrapping?
When I checked the gcc source code on shrink-wrapping as following
(gcc/function.c):
…….
rtx_insn *epilogue_seq = make_epilogue_seq ();
/* 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. */
try_shrink_wrapping (&entry_edge, prologue_seq);
/* If the target can handle splitting the prologue/epilogue into separate
components, try to shrink-wrap these components separately. */
try_shrink_wrapping_separate (entry_edge->dest);
/* If that did anything for any component we now need the generate the
"main" prologue again. Because some targets require some of these
to be called in a specific order (i386 requires the split prologue
to be first, for example), we create all three sequences again here.
If this does not work for some target, that target should not enable
separate shrink-wrapping. */
if (crtl->shrink_wrapped_separate)
{
split_prologue_seq = make_split_prologue_seq ();
prologue_seq = make_prologue_seq ();
epilogue_seq = make_epilogue_seq ();
}
…….
My understanding from the above is:
1. “try_shrink_wrapping” should NOT interact with make_epilogue_seq since only
“prologue_seq” will not touched.
2. “try_shrink_wrapping_seperate” might interact with epilogue, however, if
there is anything changed with “try_shrink_wrapping_seperate”,
make_epilogue_seq() will be called again, and then the zeroing sequence
will be generated still at the end of the routine.
So, from the above, I didn’t see any obvious issues.
But I might miss some important issues here, please let me know what I am
missing here?
Thanks a lot for any help.
Qing
>
> --
> H.J.
