From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D0AB9385773E; Wed, 17 May 2023 06:05:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0AB9385773E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684303507; bh=5+Wzd8IJo4NRQ8gf0Zp5/++d1eLzR10af1fsbBjT+EU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yxB49M8F5j7mxCetMEm6ZpUkqJuXczDj2P0pSAqMxhaTP3TIJleGMdS6f3ofXJsHM PFA5724EjGzSxDEue5qQ4tzhBDsBFxSKx7AAKtdrv90s1e4oCXFWgAS/4DTbC2rMwj TDVcvu/8FPGSP1VB2h4H+dDlDlub+hztpgdFH5z4= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017 Date: Wed, 17 May 2023 06:05: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: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D109610 Kewen Lin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linkw at gcc dot gnu.org --- Comment #12 from Kewen Lin --- By looking into this failure, I found something tricky related to the cost adjustment for this kind of destination pseudo: /* If this insn loads a parameter from its stack slot, then it represents a savings, rather than a cost, if the parameter is stored in memory. Record this fact. Similarly if we're loading other constants from memory (constant pool, TOC references, small data areas, etc) and this is the only assignment to the destination pseudo. Hongtao already has one fix for this regression (thanks!), but IMHO this tr= icky thing might affect any future adjustment on this particular cost, so I post= ed my findings here: This above adjustment can happen on the destination pseudo of a load insn w= ith one equiv note, but the equiv note can be created later by update_equiv_regs during ira (it's the case this failure here), it means this memory cost reduction isn't considered in the first pass of best class determination, w= hose resulted pref used for the second pass of best class determination can be n= ot good enough (not the best). In the 2nd pass, when scanning insn 13 r119:V2DF=3Dr117:V2DF, cost calculation would respect the pref VSX_REGS for= r117, penalizes alternative whose operand 1 have operand class NO_REGS (r117), bu= t at this time the pref isn't the best as the pref VSX_REGS determination doesn't consider the memory cost reduction, so I think we should give it a chance to re-consider NO_REGS and not to penalize that corresponding alternative. Not sure this kind of re-consideration (forgiving if it's NO_REGS) is worthy or not, actually it's independent of this regression issue, maybe I can give i= t a shot with some SPEC2017 runs.=