https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #37 from rguenther at suse dot de <rguenther at suse dot de> --- On September 1, 2019 12:05:52 PM GMT+02:00, ubizjak at gmail dot com <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154 > >--- Comment #36 from Uroš Bizjak <ubizjak at gmail dot com> --- >(In reply to Richard Biener from comment #30) > >> Hmm, it regresses the gcc.target/i386/minmax-6.c though and thus >cactusADM >> (IIRC). > >I was looking a bit into minmax6.c failure. Apparently, despite >spill/fill >cactusADM doesn't regress [1]. By avoiding subregs, spill and fill are >both in >V4SImode, so store forwarding mitigates the effects of memory access. >Thus, the >current testsuite failure is benign, and scan-asm-not should be >adjusted to >only check for SImode spill. > >OTOH, spill in SImode (32bit) and fill in V4SImode (128 bit), which is >the >consequence of using V4SImode paradoxical subreg of SImode value >disables store >forwarding and a big runtime regression in a hot loop is observed. Yeah, that might very well be the original issue. Still reg, xmm moves should be better so not sure if we should adjust the testcase. Maybe we can make two of them and assert we don't see the SImode spill with any tuning? >Based on this observation, your approach of using special patterns to >convert >SImode to V4SImode is the correct approach, and I retract my patch that >reintroduces subregs instead. > >[1] >https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_recent_big.png
