From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E12B83858CDB; Thu, 18 May 2023 15:50:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E12B83858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684425006; bh=Dfjza8mZI+i/TVisgpuslPKIE1iLNU3ZGePbqlhoDfM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Vy+ivAHGqTRnl1JbCmMA7QaZ+RtnYsHeDFgQi9L07yaj01NaOMTHwoJs4JdxoHOS1 YIlcxSx2EFE2MI2Hm+4g6d3CH0DTDAKKoqGK6LU1TgsZax7m0OhlHmVg+8IhTaFH0o EgUpWLYuRGUP3vqRxMa/WmSySP83WXiT51L06GOI= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced Date: Thu, 18 May 2023 15:50:06 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109903 --- Comment #5 from Andrew Pinski --- (In reply to Dimitri Gorokhovik from comment #4) > Hi Andrew, >=20 > I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We > want to spare the same hassle to others. Why you didn't read the documentation which is documents inline-asm. And th= ere is no way for GCC to know what you mean. >=20 > This asm doesn't write to memory, it doesn't even read any -- 'a' is pass= ed > over in the registers with aarch64 and x64_86. Oh I read the instruction wrong. >=20 > It is also very hard to see the need for early clobber here ... how comes > the version with return value doesn't need it while the other does? The a= sm > performs regular register loads. Certainly we are not marking all register > loads with early clobbers are we? The easy and fast rule is simple. If you write to an output operand before = read from an input operand, that output operand needs an early clobber. This is = how I knew what the issue was right away without even looking further into what= was going wrong. Even the documentation is clear here: "Means (in a particular alternative) that this operand is an earlyclobber operand, which is written before the instruction is finished using the input operands." The reason why sometimes it works sometimes it does not work is depedent on= the register allocator. In the case of return and first argument registers, well usually those are the same register so the register allocator wants to minimalize the number of spills and/or register moves. >=20 > WE ended up moving 'a' to output clause, it feels barely more contorted t= han > the early-clobber method. That is actually WRONG and will produce wrong code in some cases. The early clobber is the right appoarch here if you are writing to an operand before = you use all of the input operands (again this is all DOCUMENTED and has been for the over 10 years now). >=20 > > GCC does not look at the inline-asm template except while outputting th= e assembly. > Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)=