Hi Uros,
Thanks for the speedy review. The point of this patch is that (with pending changes to STV) the pand;pxor sequence isn't created until after combine, and hence doesn't/won't get caught by any of the current pre-reload/combine splitters. > -----Original Message----- > From: Uros Bizjak <ubiz...@gmail.com> > Sent: 23 May 2022 09:51 > To: Roger Sayle <ro...@nextmovesoftware.com> > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [x86 PING] Peephole pand;pxor into pandn > > On Mon, May 23, 2022 at 10:44 AM Roger Sayle > <ro...@nextmovesoftware.com> wrote: > > > > > > This is a ping of a patch from April (a dependency of another stage1 patch): > > https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593123.html > > > > This patch has been refreshed/retested against gcc 13 trunk on > > x86_64-pc-linux-gnu with make bootstrap and make -k check, both with > > and without --target_board=unix{-m32}, with no new failures. > > Ok for mainline? > > I think this should be handled in a pre-reload splitter (or perhaps combine > splitter). We have so many variants of SSE/AVX logic instructions that the > transform after reload barely makes sense (please see the number of regno > checks in the proposed patch). > > Uros. > > > 2022-05-23 Roger Sayle <ro...@nextmovesoftware.com> > > > > gcc/ChangeLog > > * config/i386/sse.md (peephole2): Convert suitable pand followed > > by pxor into pandn, i.e. (X&Y)^X into X & ~Y. > > > > Many thanks in advance, > > Roger > > -- > >
