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. > 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. Uros.
