From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 67C243858410; Mon,  4 Oct 2021 11:31:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67C243858410
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/85730] complex code for modifying lowest byte in a
 4-byte vector
Date: Mon, 04 Oct 2021 11:31:32 +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: 9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
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: <bug-85730-4-tlegX2HxUi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-85730-4@http.gcc.gnu.org/bugzilla/>
References: <bug-85730-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2021 11:31:32 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D85730

--- Comment #6 from Uro=C5=A1 Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #5)
> The GIMPLE IL is now using BIT_INSERT_EXPRs consistently for all cases and
> combine does
>=20
> Trying 8 -> 11:
>     8: {r90:SI=3Dr89:SI<<0x1;clobber flags:CC;}
>       REG_DEAD r89:SI
>       REG_UNUSED flags:CC
>    11: strict_low_part(r92:V4QI#0)=3Dr90:SI#0
>       REG_DEAD r90:SI
> Failed to match this instruction:
> (set (strict_low_part (subreg:QI (reg:V4QI 92 [ v ]) 0))
>     (ashift:QI (subreg:QI (reg:SI 89 [ v ]) 0)
>         (const_int 1 [0x1])))
>=20
> where it fails to try (add:QI (subreg...) (subreg...)) instead of the shi=
ft
> by 1.
>=20
> Not sure whether targets should have a special-case pattern here or wheth=
er
> that's for combine to un-canonicalize it?

We do have this pattern in i386.md, but please see the FIXME:

(define_insn "*ashl<mode>3_1_slp"
  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+<r>"))
        (ashift:SWI12 (match_operand:SWI12 1 "register_operand" "0")
                      (match_operand:QI 2 "nonmemory_operand" "cI")))
   (clobber (reg:CC FLAGS_REG))]
  "(!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun))
   /* FIXME: without this LRA can't reload this pattern, see PR82524.  */
   && rtx_equal_p (operands[0], operands[1])"=