On Thu, Jul 8, 2021 at 7:56 AM Segher Boessenkool <seg...@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 > > <seg...@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
