From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46E2B3858C30; Wed, 18 Oct 2023 02:29:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46E2B3858C30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697596156; bh=WjHRXKZJQOeW2rk0HM60qtkRIa8sKAGk/LrTTJJA00o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ty5NWAaJfT3mdFLTSwiPcMVAmD9xEEFUvtaZyv8tpCIb7Et37eSkEWSeJgwkEALKU esNgHF2YKV9rgp+3Fot97E3SVatdvnWQ2Cc7rUJyGB9eTIUi7WQB4eqKEYsfgxKHkB 615nWWvOCZZuJG7YUpY0M1FcvyKV6KOwyCwxpR/w= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111828] rs6000: Parse inline asm string to figure out it requires HTM feature or not. Date: Wed, 18 Oct 2023 02:29:14 +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: enhancement X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority 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=3D111828 Kewen Lin changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P4 --- Comment #8 from Kewen Lin --- (In reply to Peter Bergner from comment #6) > (In reply to Kewen Lin from comment #3) > > The motivation of this request is to try our best to make power10 attri= buted > > code inline more power8/power9 attribute code which likely includes some > > inline asm but not HTM related as the quoted OSS shows. For now, for one > > function which has any non-empty inline asm string, we would consider i= t's > > possible to have HTM code so it's unsafe to inline it. >=20 > We've hit this issue (attempting to inline some Power8/9 function into a > Power10 caller) before with another project (I forget which) and the > solution used was to add no-htm to the attribute target options (ie, > "cpu=3Dpower8,no-htm"). Yes, I agree that we already have some solutions for that, no-htm option or no-htm,htm target option attributes. I was thinking unrealistically if we d= on't have to teach users about these things (or sometimes users even don't notice this). But as you pointed out, the inline asm parsing approach looks impractical. >=20 > > Users usually think higher cpu attributed code can safely inline lower = cpu > > attributed code, but it's out of expectation for power10 code inlining > > power8/power9 code as we drops HTM from power10. If we can support it > > better, users don't need more extra efforts to teach about it. >=20 > Ideally, we could just go back in time and not enable HTM by default on > Power8/9 and force the user to always use -mhtm if they need HTM support.= =20 > That ship has sailed though. Florian Weimer raised this point in PR102059, the compatibility was the con= cern though, no further comments/discussions on this then. :( >=20 > That said, I think nearly all (all?) HTM usage on Power uses our HTM > built-in functions. Maybe we could remove OPTION_MASK_HTM from the > power8/power9 default flags and only add it back in if we detect the use = of > an HTM built-in function? > > Looking at GLIBC, Power's elision-lock.c use of our htm.h uses inline asm > with HTM instructions and not our HTM built-in functions and it doesn't > explicitly add -mhtm to the command line options like S390 does, so I thi= nk > this idea won't work. :-( Thanks for checking! Sigh...=