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

[Hongtao Liu <crazylht@gmail.com>]

On Thu, Jul 8, 2021 at 7:56 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> 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.
maybe, and if there's existed infrastructure to solve vzeroupper
issue, i'm ok to change my patch.
>
>
> Segher



-- 
BR,
Hongtao