From patchwork Fri Nov 4 16:39:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernhard Reutner-Fischer X-Patchwork-Id: 59949 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 60F4A3858283 for ; Fri, 4 Nov 2022 16:39:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60F4A3858283 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667579998; bh=MuObbbWScPKVwPty2QQRQ+byV628xUyRYVr4fMUjWzE=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=OIveVs102S14TFvS9C6rIOCUc05NcnkQ0ao5naqHoiTPF0IWqN+U+PmjFF6Tw+US/ pOmy7lXVaz5WFpPVCNek5mNaFfIg0UHNv4E2cQhSntWznEfI4a7K1uBaYszbd3by/G 3tmWMOW0sf7rFkMrKsQpQc8+wStWZ0d+y2Qfn5CQ= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 05CC9385842D for ; Fri, 4 Nov 2022 16:39:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 05CC9385842D Received: by mail-ed1-x533.google.com with SMTP id a67so8395385edf.12 for ; Fri, 04 Nov 2022 09:39:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MuObbbWScPKVwPty2QQRQ+byV628xUyRYVr4fMUjWzE=; b=uZJ5VMfq+q5EAuuK8V8eRzlNixFkjj2tmJocZbHz1Q/0Ts10IKuK2wlPimAlF3qJcl TqW9zzxcJmX7/4FEfZlNhlddeWWnQoMwTd+QdEF3YSPpdhWbULNImUmJvfh3rjKR6cDK n59uhYmVpBkyncyLVPKfy0sCQPs0dXcGK5XhLFRGmrpPUHp3okBg4Vbny+7Gmp5m9E3L lWlUzOMeAq/CQ7WhynXoJ0DE+L2Swdt4UdTXIzRase5ARpLCUP5yfl6L/Abi4eKBHEoO //xb/rnrFySIjnSwv851ud9TMlK6k2cxy5fDs/dJvhmAwSucyhGRl9ok2zuhuXlDrTs8 1dxw== X-Gm-Message-State: ACrzQf0NIQZvsVEn0Y0NQCmaDFPg3rQcxQzM7kH/5B24Oe5bHagZwmmz lkvYIXelRlorWuUWt0fyDAs= X-Google-Smtp-Source: AMsMyM42vOUrc1opdjQhCdUgbTjcRjeHe7M6vUIJULDPzTg6G2fOFDEMUjOVqcyzIO+JGNpLV2zw5w== X-Received: by 2002:aa7:d5ca:0:b0:464:4ac8:d265 with SMTP id d10-20020aa7d5ca000000b004644ac8d265mr8147554eds.265.1667579964449; Fri, 04 Nov 2022 09:39:24 -0700 (PDT) Received: from nbbrfq ([2001:871:227:81c4:d7ff:3a0e:48da:5fe3]) by smtp.gmail.com with ESMTPSA id g18-20020a17090604d200b00788c622fa2csm2020400eja.135.2022.11.04.09.39.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 09:39:23 -0700 (PDT) Date: Fri, 4 Nov 2022 17:39:20 +0100 To: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: [PATCH] symtab: also change RTL decl name [was: RFH: attr target_clones default assembler name ignored?] Message-ID: <20221104173920.5313660c@nbbrfq> In-Reply-To: <20221103232355.5eb1d235@nbbrfq> References: <20221103232355.5eb1d235@nbbrfq> MIME-Version: 1.0 X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Bernhard Reutner-Fischer via Gcc-patches From: Bernhard Reutner-Fischer Reply-To: Bernhard Reutner-Fischer Cc: rep.dot.nop@gmail.com Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" On Thu, 3 Nov 2022 23:23:55 +0100 Bernhard Reutner-Fischer wrote: > Hi! > > I encounter a problem/pilot error when using the target_clones > attribute. > > The symptom is that the default clone is not renamed in the output and > thus conflicts with the (proper) global name which is used for the > ifunc: > > $ nl -ba < /tmp/cc3jBX3x.s | grep sub1 > 12 .type __m_MOD_sub1, @function > 13 __m_MOD_sub1: > 35 .size __m_MOD_sub1, .-__m_MOD_sub1 > ... > 87 __m_MOD_sub1.resolver: > 95 movl $__m_MOD_sub1.avx, %eax > 104 movl $__m_MOD_sub1, %eax > 105 movl $__m_MOD_sub1.sse, %edx > 110 .size __m_MOD_sub1.resolver, .-__m_MOD_sub1.resolver > 111 .globl __m_MOD_sub1 > 112 .type __m_MOD_sub1, @gnu_indirect_function > 113 .set __m_MOD_sub1,__m_MOD_sub1.resolver > > I think that line 13 and 104 should talk about __m_MOD_sub1.default. > > AFAICT the target_clones attr is built well. > gcc/multiple_target.cc:expand_target_clones() adds the required > attr "target" "default" > and properly does: > (gdb) p old_name > $6 = 0x7ffff6dfc090 "__m_MOD_sub1" > (gdb) call debug_tree ( DECL_ASSEMBLER_NAME (decl) ) > > (gdb) n > 301 && DECL_RTL_SET_P (decl)) > (gdb) n > 300 if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) > (gdb) n > 304 SET_DECL_ASSEMBLER_NAME (decl, name); > (gdb) n > 305 if (alias) > (gdb) call debug_tree ( DECL_ASSEMBLER_NAME (decl) ) > > > So if that would have been used for real, all would be fine i think. > > But still, that name is somehow not used, see fnname: > #0 assemble_start_function (decl=, fnname=fnname@entry=0x7ffff6dfc090 "__m_MOD_sub1") at ../../../src/gcc-13.mine/gcc/varasm.cc:1979 > I'd be grateful for help to understand why/who chooses to pick an unpleasant > name, and, primarily, how to avoid that problem. > > Thoughts or hints? > TIA! > PS: Should i have rather asked on gcc-help? We make_decl_rtl rather early when creating a function and set the name to the (unversioned, from the POV of target_clones) initial name of the function. Then we parse the attributes and attach it to the fndecl when lowering. Later on the ME creates the clones and renames the function via symbol_table::change_decl_assembler_name() which changes just the DECL_ASSEMBLER_NAME and not the name in the DECL_RTL. With this, the target_clones attribute works for me from the Fortran FE. The following tests cleanly for --enable-languages=c,fortran,c++,lto Ok for trunk? PS: I did not look if it would be possible to change the way this fnname (as per get_fnname_from_decl()) is stored in both RTL and tree in apparently two different places. I would have assumed that varasm uses a name via cgraph but that's obviously not (always) the case. gcc/ChangeLog: * symtab.cc: Remove stray comment. (symbol_table::change_decl_assembler_name): Also update the name in DECL_RTL. diff --git a/gcc/symtab.cc b/gcc/symtab.cc index f2d96c0268b..53a1a2a26bf 100644 --- a/gcc/symtab.cc +++ b/gcc/symtab.cc @@ -153,10 +153,8 @@ symbol_table::decl_assembler_name_equal (tree decl, const_tree asmname) return assembler_names_equal_p (decl_str, asmname_str); } -/* Returns nonzero if P1 and P2 are equal. */ - /* Insert NODE to assembler name hash. */ void symbol_table::insert_to_assembler_name_hash (symtab_node *node, @@ -302,8 +301,12 @@ symbol_table::change_decl_assembler_name (tree decl, tree name) && DECL_RTL_SET_P (decl)) warning (0, "%qD renamed after being referenced in assembly", decl); SET_DECL_ASSEMBLER_NAME (decl, name); + /* Set the new name in rtl. */ + if (DECL_RTL_SET_P (decl)) + XSTR (XEXP (DECL_RTL (decl), 0), 0) = IDENTIFIER_POINTER (name); + if (alias) { IDENTIFIER_TRANSPARENT_ALIAS (name) = 1; TREE_CHAIN (name) = alias;