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 2520D3858430; Tue, 16 Nov 2021 02:58:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2520D3858430
From: "guihaoc 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: Tue, 16 Nov 2021 02:58:51 +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: guihaoc 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-zn2vMs5Lzg@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: Tue, 16 Nov 2021 02:58:52 -0000

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

--- Comment #4 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
For the second issue, I drafted following insn_and_split pattern. It tries =
to
combine the shift and ior when the nonzero_bits of operands[3] matches the
condition.=20

(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_operand"
"r")
                                      (match_operand:SI 2 "const_int_operan=
d"
"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")])

But I found that nonzero_bits can't return an exact value except in combine
pass. 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.

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

(set (reg:DI 123)
    (ior:DI (ashift:DI (reg:DI 125)
            (const_int 32 [0x20]))
        (reg:DI 126)))

(set (reg:DI 123)
    (ior:DI (ashift:DI (reg:DI 125)
                       (const_int 32 [0x20]))
            (and:DI (reg:DI 126)
                    (const_int 4294967295 [0xfffffff]))))=