[PATCH 1/2] CALL_INSN may not be a real function call.

[Segher Boessenkool]

On Wed, Jul 07, 2021 at 11:32:59PM +0800, Hongtao Liu wrote:
> On Wed, Jul 7, 2021 at 10:54 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > So, a "FAKE_CALL" is very much a *real* call, on the RTL level, which is
> > where we are here.  But you want it to be treated differently because it
> > will eventually be replaced by different insns.
> It's CALL_INSN on the rtl level,  but it's just a normal instruction
> that it doesn't have a call stack, and it doesn't affect the control
> flow

There is no such thing as "call stack" (whatever that may mean) to do
with the RTL "call" insn.  How the return address is stored (if at all)
is up to the target.  Many do not store the return address on the stack
(for example they have an RA or LR register for it).  Those that do
store it on a stack do not all change the stack pointer.

In RTL, it *does* change the control flow.  If you don't like that,
don't use a "call" insn.  You will have to update a *lot* more code
than you did, otherwise.

> > So because of this one thing (you need to insert partial clobbers) you
> > force all kinds of unrelated code to have changes, namely, code thatt
> > needs to do something with calls, but now you do not want to have that
> > doone on some calls because you promise that call will disappear
> > eventually, and it cannot cause any problems in the mean time?
> >
> > I am not convinced.  This is not design, this is a terrible hack, this
> > is the opposite direction we should go in.
> 
> Quote from  https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570634.html
> 
> > Also i grep CALL_P or CALL_INSN in GCC source codes, there are many
> > places which hold the assumption CALL_P/CALL_INSN is a real call.
> > Considering that vzeroupper is used a lot on the i386 backend, I'm a
> > bit worried that this implementation solution will be a bottomless
> > pit.
> 
> Maybe, but I think the same is true for CLOBBER_HIGH.  If we have
> a third alternative then we should consider it, but I think the
> call approach is still going to be less problematic then CLOBBER_HIGH.
> 
> The main advantage of the call approach is that the CALL_P handling
> is (mostly) conservatively correct and performance problems are just
> a one-line change.  The CLOBBER_HIGH approach instead requires
> changes to the way that passes track liveness information for
> non-call instructions (so is much more than a one-line change).
> Also, treating a CLOBBER_HIGH like a CLOBBER isn't conservatively
> correct, because other code might be relying on part of the register
> being preserved.

And this isn't a one-line change either, and it is only partial already,
and we don't know how deep the rabbit hole goes.


Segher