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

[Hongtao Liu <crazylht@gmail.com>]

On Tue, Jul 6, 2021 at 8:03 AM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 7/5/2021 5:30 PM, Segher Boessenkool wrote:
> > Hi!
> >
> > I ran into this in shrink-wrap.c today.
> >
> > On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote:
> >> Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a
> >> fake call, it won't have its own function stack.
> > Could you document somewhere what a "fake call" *is*?  Including what
> > that means to RTL, how this is expected to be used, etc.?  In rtl.h is
> > fine with me, but as it is, no one can know when to use this.  What does
> > "its own function stack" mean in the description here?  You can only put
> > FAKE_CALL on functions that do not have a stack frame?  But that is
> > never true on x86, so that cannot be it, unless there isn't a call
> > instruction at all?  But then, why use an RTL call insn for this?
> >
> > Other targets simply do not use an RTL "call" when they want to hide
> > such an instruction, why can't you do that here, wouldn't that work much
> > better?  There are many more insns that you may want to hide.  The
> > traditional solution is to use unspecs, which very directly hides all
> > details.
> It reminds me a bit of millicode calls on the PA or calls to special
> routines in libgcc.  They're calls to functions, but those functions do
> not follow the standard ABI.  I'd like to remove
> INSN_REFERENCES_ARE_DELAYED and instead use the new fake call mechanism,
> but I haven't tried it or even looked at the fake call bits enough to
> know if that's possible.
Fake call is used for TARGET_INSN_CALLEE_ABI which is used for
vzeroupper in i386.
vzeroupper clobber high part of ymm registers but leave low part
unchanged, define it and call_insn with special callee ABI so that
RA/CSE knows this instruction kills high parts of ymm registers, and
can still optimize with lowpart.
I didn't handle FAKE_CALL_P thoroughly in the RTL, but only changed
the necessary parts so that I could get my patch to survive the
regression test(also fix some optimization issues I observed).
n through the tests>
> jeff



-- 
BR,
Hongtao