From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 70AD63858CDA; Tue, 24 Oct 2023 03:33:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70AD63858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1698118386; bh=VXEOI/dehYgfl3af/OaxcL0w+yn+DJc161vDNVk5spg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A0yjXqHeHvkYv8vLXyq7Yr7SsTV221FdjJQZ+aQtL7OcpvNoDpR+27EUUxWSF3qpg DEKahZZpJt3XOfN7P+VMiqRqtZI7fSs6534rDa1I4fssvQPBQCKJQ5nXCl6NMJ9oKs CBJCDY2WeRechXsYMCKN7VQpHK+GUQMV7PVwMcr4= 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: Tue, 24 Oct 2023 03:33:04 +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: 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 --- Comment #9 from Kewen Lin --- Peter had a check on gnu assembler (Thanks!) and found that even with -mpow= er10 specified it's still able to assemble HTM insns, so it means that for some callee with power8 attributed has HTM inline asm, it can be successfully compiled when it's inlined to a caller with power10 attributed (at least gnu assembler involved). It sounds weird and unexpected that power10 attributed function calls one power8 attributed function which has HTM insns, but it w= ould only break during runtime when running on Power10 (weird but safe if no pow= er10 insns are exploited and run on power8 or power9 machine), so the point here= is to avoid inconsistent behaviors before and after inlining. As Peter suggested, I think it's a good idea to make the inlining aggressiv= e on inline asm when the involved assembler can support that, but considering th= at gcc configuration support --with-as and it's possible to have an assembler which doesn't support HTM insns at power10 (like in future gnu assembler changes its behavior if users complains, or other assembler alternatives de= cide not to support it to avoid confusion etc.), it seems that we should also ch= eck the given assembler's behavior at configuration?=