On Sat, Feb 9, 2019 at 7:03 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > On 2/9/19, H.J. Lu <hjl.to...@gmail.com> wrote: > > On Sat, Feb 9, 2019 at 6:09 AM Uros Bizjak <ubiz...@gmail.com> wrote: > >> > >> On 2/9/19, H.J. Lu <hjl.to...@gmail.com> wrote: > >> > In 64-bit mode, SSE2 can be used to emulate MMX instructions without > >> > 3DNOW. We can use SSE2 to support 64-bit vectors. > >> > > >> > PR target/89021 > >> > * config/i386/i386.h (TARGET_MMX_WITH_SSE): New. > >> > * config/i386/i386.h (VALID_SSE2_REG_MODE): Allow 64-bit vector > >> > modes for TARGET_MMX_WITH_SSE. > >> > (SSE_REG_MODE_P): Likewise. > >> > --- > >> > gcc/config/i386/i386.h | 20 ++++++++++++++++++-- > >> > 1 file changed, 18 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > >> > index 83b025e0cf5..c1df3ec3326 100644 > >> > --- a/gcc/config/i386/i386.h > >> > +++ b/gcc/config/i386/i386.h > >> > @@ -585,6 +585,11 @@ extern unsigned char > >> > ix86_arch_features[X86_ARCH_LAST]; > >> > > >> > #define TARGET_FISTTP (TARGET_SSE3 && TARGET_80387) > >> > > >> > +/* In 64-bit mode, SSE2 can be used to emulate MMX instructions. > >> > + FIXME: All 3DNOW patterns needs to be updated with SSE emulation. > >> > */ > >> > +#define TARGET_MMX_WITH_SSE \ > >> > + (TARGET_64BIT && TARGET_SSE2 && !TARGET_3DNOW) > >> > + > >> > extern unsigned char x86_prefetch_sse; > >> > #define TARGET_PREFETCH_SSE x86_prefetch_sse > >> > > >> > @@ -1143,9 +1148,16 @@ extern const char *host_detect_local_cpu (int > >> > argc, > >> > const char **argv); > >> > || (MODE) == V4SImode || (MODE) == V4SFmode || (MODE) == V8HImode \ > >> > || (MODE) == TFmode || (MODE) == V1TImode) > >> > > >> > +/* NB: Don't use VALID_MMX_REG_MODE with TARGET_MMX_WITH_SSE since we > >> > + want to include 8-byte vector modes, like V2SFmode, but not DImode > >> > + nor SImode. */ > >> > >> This is strange, since we already allow all MMX modes in SSE > >> registers. Please see ix86_hard_regno_mode_ok, where for SSE_REG_P, we > >> return: > >> > >> return ((TARGET_AVX > >> && VALID_AVX256_REG_OR_OI_MODE (mode)) > >> || VALID_SSE_REG_MODE (mode) > >> || VALID_SSE2_REG_MODE (mode) > >> || VALID_MMX_REG_MODE (mode) > >> || VALID_MMX_REG_MODE_3DNOW (mode)); > >> > >> I'd expect that changed VALID_SSE2_REG_MODE affects only > >> ix86_vector_mode_supported_p when MMX is disabled and perhaps > >> ix86_set_reg_reg_cost cost function. > >> > >> Are there any concrete issues when allowing all MMX (including 3DNOW?) > >> modes in VALID_SSE2_REG_MODE? > > > > The problem is with DImode and SImode. All other vector modes, including > > V2SF is OK. With DImode and SImode, I got following regressions: > > > > FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias > > cannot be created; target is discardable" > > FAIL: gcc.dg/pr39323-3.c scan-assembler .align[ \t]+(268435456|28)[ \t]*\n > > FAIL: go test misc/cgo/testcarchive > > > > gcc.dg/pr39323-3.c is due to > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89261 > > > > and > > > > /* Decide whether a variable of mode MODE should be 128 bit aligned. */ > > #define ALIGN_MODE_128(MODE) \ > > ((MODE) == XFmode || SSE_REG_MODE_P (MODE)) > > Hm, this is a bit worrying, we don't want to introduce ABI > incompatibilites w.r.t. alignment. We still need to be ABI compatible > for MMX values and emit unaligned loads/stores when necessary.
We need to audit all usages of SSE_REG_MODE_P and VALID_SSE2_REG_MODE. And I don't think we should put DI and SI in them. > > SSE_REG_MODE_P and VALID_SSE2_REG_MODE are used in many different > > places. i386 backend may not be prepared to deal them in SSE_REG_MODE_P > > nor VALID_SSE2_REG_MODE. > > I think we have to review the usage of these two changed defines to > prevent any ABI issues or other hidden issues. > Absolutely. -- H.J.
