On Thu, May 13, 2021 at 7:52 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Jakub Jelinek <ja...@redhat.com> writes: > > On Thu, May 13, 2021 at 12:32:26PM +0100, Richard Sandiford wrote: > >> Jakub Jelinek <ja...@redhat.com> writes: > >> > On Thu, May 13, 2021 at 11:43:19AM +0200, Uros Bizjak wrote: > >> >> > > Bootstrapped and regtested on X86_64-linux-gnu{-m32,} > >> >> > > Ok for trunk? > >> >> > > >> >> > Some time ago a support for CLOBBER_HIGH RTX was added (and later > >> >> > removed for some reason). Perhaps we could resurrect the patch for the > >> >> > purpose of ferrying 128bit modes via vzeroupper RTX? > >> >> > >> >> https://gcc.gnu.org/legacy-ml/gcc-patches/2017-11/msg01325.html > >> > > >> > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01468.html > >> > is where it got removed, CCing Richard. > >> > >> Yeah. Initially clobber_high seemed like the best appraoch for > >> handling the tlsdesc thing, but in practice it was too difficult > >> to shoe-horn the concept in after the fact, when so much rtl > >> infrastructure wasn't prepared to deal with it. The old support > >> didn't handle all cases and passes correctly, and handled others > >> suboptimally. > >> > >> I think it would be worth using the same approach as > >> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01466.html for > >> vzeroupper: represent the instructions as call_insns in which the > >> call has a special vzeroupper ABI. I think that's likely to lead > >> to better code than clobber_high would (or at least, it did for tlsdesc).
>From an implementation perspective, I guess you're meaning we should implement TARGET_INSN_CALLEE_ABI and TARGET_FNTYPE_ABI in the i386 backend. > > > > Perhaps a magic call_insn that is split post-reload into a normal insn > > with the sets then? > > I'd be tempted to treat it is a call_insn throughout. The unspec_volatile > means that we can't move the instruction, so converting a call_insn to an > insn isn't likely to help from that point of view. The sets are also > likely to be handled suboptimally compared to the more accurate register > information attached to the call: all code that handles calls has to be > prepared to deal with partial clobbers, whereas most code dealing with > sets will assume that the set does useful work, and that the rhs of the > set is live. > > Thanks, > Richard > -- BR, Hongtao