On Thu, Jul 14, 2022 at 3:22 PM Uros Bizjak via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Thu, Jul 14, 2022 at 7:33 AM liuhongt <hongtao....@intel.com> wrote: > > > > And split it to GPR-version instruction after reload. > > > > > ?r was introduced under the assumption that we want vector values > > > mostly in vector registers. Currently there are no instructions with > > > memory or immediate operand, so that made sense at the time. Let's > > > keep ?r until logic instructions with mem/imm operands are introduced. > > > So, for the patch that adds 64-bit vector logic in GPR, I would advise > > > to first introduce only register operands. mem/imm operands should be > > Update patch to add ?r to 64-bit bit_op patterns. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > No big imact on SPEC2017(Most same binary). > > The problem with your approach is with the combine pass, where combine > first tries to recognize the combined instruction without clobber, > before re-recognizing instruction with added clobber. So, if a forward > propagation happens, the combine will *always* choose the insn variant > without GPR. Thank you for the explanation, I really did not know this point. > > So, the solution with VI_16_32 is to always expand with a clobbered > version that is split to either SImode or V16QImode. With 64-bit > instructions, we have two additional complications. First, we have a > native MMX instruction, and we have to split to it after reload, and > second, we have a builtin that expects vector insn. > > To solve the first issue, we should change the mode of > "*mmx<code><mode>" to V1DImode and split your new _gpr version with > clobber to it for !GENERAL_REG_P operands. > > The second issue could be solved by emitting V1DImode instructions > directly from the expander. Please note there are several expanders > that expect non-clobbered logic insn in certain mode to be available, > so the situation can become quite annoying... Yes. It looks like it would add a lot of code complexity, I'll hold the patch for now. > > Uros.
-- BR, Hongtao