From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BF802385829C; Tue, 5 Jul 2022 17:02:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF802385829C From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/105854] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: sse2_lshrv1ti3) Date: Tue, 05 Jul 2022 17:02:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 17:02:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105854 --- Comment #7 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a commit r13-1508-g02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a Author: Roger Sayle Date: Tue Jul 5 18:00:00 2022 +0100 UNSPEC_PALIGNR optimizations and clean-ups on x86. This patch is a follow-up to Hongtao's fix for PR target/105854. That fix is perfectly correct, but the thing that caught my eye was why is the compiler generating a shift by zero at all. Digging deeper it turns out that we can easily optimize __builtin_ia32_palignr for alignments of 0 and 64 respectively, which may be simplified to moves of the highpart and lowpart respectively. After adding optimizations to simplify the 64-bit DImode palignr, I started to add the corresponding optimizations for vpalignr (i.e. 128-bit). The first oddity is that sse.md uses TImode and a special SSESCALARMODE iterator, rather than V1TImode, and indeed the comment above SSESCALARMODE hints that this should be "dropped in favor of VIMAX_AVX2_AVX512BW". Hence this patch includes the migration of _palignr to use VIMAX_AVX2_AVX512BW, basically using V1TImode instead of TImode for 128-bit palignr. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=3Dunix{-,32}, with no new failures. Ok for mainline? 2022-07-05 Roger Sayle Hongtao Liu gcc/ChangeLog * config/i386/i386-builtin.def (__builtin_ia32_palignr128): Cha= nge CODE_FOR_ssse3_palignrti to CODE_FOR_ssse3_palignrv1ti. * config/i386/i386-expand.cc (expand_vec_perm_palignr): Use V1TImode and gen_ssse3_palignv1ti instead of TImode. * config/i386/sse.md (SSESCALARMODE): Delete. (define_mode_attr ssse3_avx2): Handle V1TImode instead of TImod= e. (_palignr): Use VIMAX_AVX2_AVX512BW as a mode iterator instead of SSESCALARMODE. (ssse3_palignrdi): Optimize cases where operands[3] is 0 or 64, using a single move instruction (if required). gcc/testsuite/ChangeLog * gcc.target/i386/ssse3-palignr-2.c: New test case.=