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 2230A3858417; Tue, 29 Nov 2022 19:12:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2230A3858417
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669749179;
	bh=qseif6QJ4uauJi8VCxDNoHCjxrFRKf+DEOCHOOXeXM4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=hCfotT0t3S3y+RmocsfXv1pLEhbCIpKaAGJxGe8Ftg3HSGXGJTJMIz8cDETEQ+0jZ
	 BnfCLGhQDm8NZUNFf9dFCcn1WeuXaW1pW9BlYCqdazI8lDq3hJkwkHqsL5pOCgQT4K
	 5hZEF2yai1beEfnzDXCEGISvXfpzy81Sc/5UNgJA=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/107627] [13 Regression] int128_t shift generates extra
 xor/or.
Date: Tue, 29 Nov 2022 19:12:58 +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: 13.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107627-4-ng0cPh4o31@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107627-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107627-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #4)
> Perhaps:
> (define_insn_and_split "*concat<mode><dwi>3_1"
>   [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=3Dro,r,r")
>         (any_or_plus:<DWI>
>           (ashift:<DWI> (match_operand:<DWI> 1 "nonimmediate_operand"
> "r,o,r")
>                         (match_operand:<DWI> 2 "const_int_operand"))
>           (zero_extend:<DWI> (match_operand:DWIH 3 "nonimmediate_operand"
> "r,r,o"))))]
>=20
> I hope this helps.

You're probably right, but:
1) I don't see why operands[1] or operands[3] can't be both memory operands
2) I don't see why they should use o constraint, while for operands[0] we n=
eed
   it to be offsettable, because we need to refer to both of its halves, but
   for the others we just refer to those memories or their low parts (which=
 on
   little endian comes first).  Though, maybe it isn't a good idea to narrow
   128-bit or 64-bit loads to just 64-bit or 32-bit loads of their low half,
   the former might trap while the latter might succeed; so maybe limit
   nonimmediate_operand on inputs to zero_extend operands?
On the other side, split_double_concat needs to take into account when the
destination
and/or source are MEMs and some registers are used in their addresses.=