From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 83A6F3858C36; Fri, 25 Aug 2023 21:17:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83A6F3858C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1692998260; bh=9OUgAeDeQCvIIeInHNl4tvn6ruXcTDvN3ShIs+REikw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iPppiCO25l1u0z/s+NUvp0AZNv+FiqeT3Eeu0y7ACFbJyhXUmuj9NN7pOR8DMMkLE zkLuZ94avZdxG5YNPOJayaSms6mPB+pfOCvx4YqUM7EdqXkt6XBf2eKthc0wQdxlz2 dBY/ef7BMHw+dl8UgNfWT5XJCTf/gWB5GV0S7jg4= From: "juergen.reuter at desy dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer Date: Fri, 25 Aug 2023 21:17:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: juergen.reuter at desy dot de 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: 14.0 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110311 --- Comment #52 from J=C3=BCrgen Reuter --- (In reply to Jakub Jelinek from comment #51) > The easiest would be to bisect gcc in the suspected ranges, that way you'd > know for sure which git commit introduced the problem and which > fixed/"fixed" it. > If it is about what the compiler emits, one doesn't have to build whole g= cc > from scratch each time, but can just --disable-bootstrap build it and dur= ing > bisection > whenever git is updated just ./config.status --recheck; ./config.status; > make -jN in libcpp, libiberty and gcc subdirectories and use f951/gfortran > binariers from that instead of the ones from the initial build to build y= our > project. This was the offending commit by Richard Sayle, on Saturday June 17: https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D96c3539f2a38134cb76d8ab= 2e924e0dc70b2ccbd =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D i386: Two minor tweaks to ix86_expand_move. This patch splits out two (independent) minor changes to i386-expand.cc's ix86_expand_move from a larger patch, given that it's better to review and commit these independent pieces separately from a more complex patch. The first change is to test for CONST_WIDE_INT_P before calling ix86_convert_const_wide_int_to_broadcast. Whilst stepping through this function in gdb, I was surprised that the code was continually jumping into this function with operands that obviously weren't appropriate. The second change is to generalize the optimization for efficiently moving a TImode value to V1TImode (via V2DImode), to cover all 128-bit vector modes. Hence for the test case: typedef unsigned long uv2di __attribute__ ((__vector_size__ (16))); uv2di foo2(__int128 x) { return (uv2di)x; } we'd previously move via memory with: foo2: movq %rdi, -24(%rsp) movq %rsi, -16(%rsp) movdqa -24(%rsp), %xmm0 ret with this patch we now generate with -O2 (the same as V1TImode): foo2: movq %rdi, %xmm0 movq %rsi, %xmm1 punpcklqdq %xmm1, %xmm0 ret and with -O2 -msse4 the even better: foo2: movq %rdi, %xmm0 pinsrq $1, %rsi, %xmm0 ret The new test case is unimaginatively called sse2-v1ti-mov-2.c given the original test case just for V1TI mode was called sse2-v1ti-mov-1.c. 2023-06-17 Roger Sayle gcc/ChangeLog * config/i386/i386-expand.cc (ix86_expand_move): Check that OP1 is CONST_WIDE_INT_P before calling ix86_convert_wide_int_to_broadcast. Generalize special case for converting TImode to V1TImode to handle all 128-bit vector conversions. gcc/testsuite/ChangeLog * gcc.target/i386/sse2-v1ti-mov-2.c: New test case. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Now the question is, was this commit later reverted? Or changed in a differ= ent manner=