On Thu, Jul 28, 2022 at 9:43 AM Roger Sayle <ro...@nextmovesoftware.com> wrote: > > > This patch resolves PR target/106450, some more fall-out from more > aggressive TImode scalar-to-vector (STV) optimizations. I continue > to be caught out by how far TImode STV has diverged from DImode/SImode > STV, and therefore requires additional (unexpected) tweaking. Many > thanks to H.J. Lu for pointing out timode_remove_non_convertible_regs > needs to be extended to handle XOR (and other new operations). > > Unhelpfully the comment above this function states that it's the TImode > version of "remove_non_convertible_regs", which doesn't exist anymore, > so I've resurrected an explanatory comment from the git history. > By refactoring the checks for hard regs and already "marked" regs > into timode_check_non_convertible_regs itself, all its callers are > simplified. This patch then uses GET_RTX_CLASS to generically handle > unary and binary operations, calling timode_check_non_convertible_regs > on each TImode register operand in the single_set's SET_SRC. > > This patch has been tested 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? > > > 2022-07-28 Roger Sayle <ro...@nextmovesoftware.com> > > gcc/ChangeLog > PR target/106450 > * config/i386/i386-features.cc (timode_check_non_convertible_regs): > Do nothing if REGNO is set in the REGS bitmap, or is a hard reg. > (timode_remove_non_convertible_regs): Update comment. > Call timode_check_non_convertible_regs on all register operands > of supported (binary and unary) operations.
Should we use df_ref ref; FOR_EACH_INSN_USE (ref, insn) if (!DF_REF_REG_MEM_P (ref)) timode_check_non_convertible_regs (candidates, regs, DF_REF_REGNO (ref)); to check each use? > gcc/testsuite/ChangeLog > PR target/106450 > * gcc.target/i386/pr106450.c: New test case. > > > Thanks in advance, > Roger > -- > -- H.J.