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 63D13385840E; Mon, 22 Nov 2021 19:51:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63D13385840E
From: "segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/93453] PPC: rldimi not taken into account to avoid
 shift+or
Date: Mon, 22 Nov 2021 19:51:05 +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: 8.3.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: segher at gcc dot gnu.org
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-93453-4-OEtsA6Wkae@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-93453-4@http.gcc.gnu.org/bugzilla/>
References: <bug-93453-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, 22 Nov 2021 19:51:05 -0000

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to HaoChen Gui from comment #4)
> (define_insn_and_split "*rotl<mode>3_insert_8"
>   [(set (match_operand:GPR 0 "gpc_reg_operand" "=3Dr")
>         (plus_ior_xor:GPR (ashift:GPR (match_operand:GPR 1 "gpc_reg_opera=
nd" "r")
>                                       (match_operand:SI 2 "const_int_oper=
and" "n"))
>                           (match_operand:GPR 3 "gpc_reg_operand" "0")))]
>   "INTVAL (operands[2]) > 0
>    && (nonzero_bits (operands[3], <MODE>mode)
>        < HOST_WIDE_INT_1U << INTVAL (operands[2]))"
> {
>   if (<MODE>mode =3D=3D SImode)
>     return "rlwimi %0,%1,%h2,0,31-%h2";
>   else
>     return "rldimi %0,%1,%H2,0";
> }
>   "&& 1"
>   [(set (match_dup 0)
>         (ior:GPR (and:GPR (match_dup 3)
>                           (match_dup 4))
>                  (ashift:GPR (match_dup 1)
>                              (match_dup 2))))]
> {
>   operands[4] =3D GEN_INT ((HOST_WIDE_INT_1U << INTVAL (operands[2])) - 1=
);
> }
>   [(set_attr "type" "insert")])
>=20
> But I found that nonzero_bits can't return an exact value except in combi=
ne
> pass.

It can return a different value after the combine pass, yes.  But making the
version of nonzero_bits used by combine be the generic version would be a b=
ig
regression, and the version used by combine cannot be used anywhere else (it
was an extension of flow.c originally, but this wasn't ported to the datafl=
ow
framework).

I planned to fix this for GCC 12, but we are in stage 3 already :-)

> So the pattern finally can't be split to pattern of
> 'rotl<mode>3_insert_3'. Also if the pass after combine changes the insn, =
it
> can't be recognized as the nonzero_bits doesn't return exact value in that
> pass.
>=20
> I am thinking if we can convert third operand to "reg and a mask" when the
> nonzero_bits is known in combine pass. Thus the pattern can be directly
> combined to 'rotl<mode>3_insert_3'.=20=20
>=20
> (set (reg:DI 123)
>     (ior:DI (ashift:DI (reg:DI 125)
>             (const_int 32 [0x20]))
>         (reg:DI 126)))
>=20
> (set (reg:DI 123)
>     (ior:DI (ashift:DI (reg:DI 125)
>                        (const_int 32 [0x20]))
>             (and:DI (reg:DI 126)
>                     (const_int 4294967295 [0xfffffff]))))

Will nothing modify it back?=