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 77CF438582AF; Wed,  3 Aug 2022 08:06:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 77CF438582AF
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106069] [12/13 Regression] wrong code with -O
 -fno-tree-forwprop -maltivec on ppc64le
Date: Wed, 03 Aug 2022 08:06:46 +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: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106069-4-Kl9jzwAfvN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106069-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106069-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: Wed, 03 Aug 2022 08:06:47 -0000

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

--- Comment #21 from Kewen Lin <linkw at gcc dot gnu.org> ---
I didn't look into this in details, but something in the culprit commit cau=
ght
my eyes, take altivec_vmrghh as example:

Before the patch, the pattern

   [(set (match_operand:V8HI 0 "register_operand" "=3Dv")
         (vec_select:V8HI
           (vec_concat:V16HI
             (match_operand:V8HI 1 "register_operand" "v")
             (match_operand:V8HI 2 "register_operand" "v"))
           (parallel [(const_int 0) (const_int 8)
                      (const_int 1) (const_int 9)
                      (const_int 2) (const_int 10)
                      (const_int 3) (const_int 11)])))]

can match vmrghh on BE while vmrglh on LE. It indicates this pattern has
different semantic from underlying instruction perspectives.

After the patch, this pattern only matches vmrghh.

IMHO, this part has semantic change before and after the patch. The code be=
fore
the patch looks more reasonable to me, since the pattern can have different
meanings on BE and LE (underlying behavior).=