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 0FDD3385700D; Tue,  4 Jul 2023 18:12:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FDD3385700D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688494338;
	bh=qRWe3zIA6qkupbLcnc9z7hTqpCU3FHG61YDz1LYlqSI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=eBQLIRKGK+QlgZ5DpodPE0UdtkosR+A9cNYe1V7FBcz2KaYnDipMLstg8+XI/pGn4
	 BJngYa+1cf8NdJeGkY8O4Lfjr+F5ZEfUG8WtY/elxTINd3EZD4a9GhhQZaTxhmy+ls
	 TT9CcFE5ptwFsIoXBEByIlC1sJYHHDV4rp1HzcXI=
From: "moncef.mechri at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110551] [11/12/13/14 Regression] an extra mov when doing
 128bit multiply
Date: Tue, 04 Jul 2023 18:12:17 +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: 11.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: moncef.mechri 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-110551-4-HPdwWHdQY0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110551-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110551-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=3D110551

--- Comment #3 from Moncef Mechri <moncef.mechri at gmail dot com> ---
> Please next time attach (which you can do paste in the box) or paste inli=
ne
> the testcase rather than just link to godbolt .

Noted. Apologies.

> It is an older regression though.
> ```
> #include <stdint.h>
>=20
> void mulx64(uint64_t *x, uint64_t *t)
> {
>     __uint128_t r =3D (__uint128_t)*x * 0x9E3779B97F4A7C15ull;
>     *t =3D (uint64_t)r ^ (uint64_t)( r >> 64 );
> }
> ```
>=20
> It is just an extra mov.
>=20
> Also the mulx should have allowed the register allocator to do better but=
 it
> was worse ...

It is true that with this new test case, all GCC versions (including GCC 10)
seem to suffer from both issues reported in the original post.

But the original test case only exhibits suboptimal codegen for GCC >=3D 11=
, as
shown in the godbolt link shared above.=