From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 67A093858D28 for ; Sat, 14 May 2022 22:48:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67A093858D28 Received: by mail-pf1-x432.google.com with SMTP id x52so10779413pfu.11 for ; Sat, 14 May 2022 15:48:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=vGrN8geq5EgG5lImPF+MvF+2PNlsnOU9EF+WipyA5Vw=; b=ancHVrQR2E2d6PBGwzeZ/4BNu6n1vGo0bKkhq9cJnzX2lKNrwMPuQPRqHUmPpx5Zbn s8fq57Ym028MMbluk49AFLBeobeiolFi1UTHf7COF69BnLV5XdJ8JMwgafuYVt8I6vGg httU4Fh4RE2LINRf3Kg9/J6CnX9ilIQUsKAWLC59WhCPrMy0tJoPo4pDdi/lHKVf8Fb/ ZpM86fZwbBjGCaBghYMNNK1aMOdR3qsESWjGJKG9rSpogUkVTqyBxNyoMcC/1UevXqF0 nf8EgXus3jqhVLOzxlG4ae+FukqPoZ6ZIEY1LZzhPK7rhOl07jdB5daYSWwmnf15PZNR FwFw== X-Gm-Message-State: AOAM530gnULe8/qwbi0l5qo4OMrSJf8jzOmvC690gIb0RUnDVndDgqCS gCQPcwvan8Xr+CtVmfBov6Lg6AFuw/1lqw== X-Google-Smtp-Source: ABdhPJwLQu/JYIHokyZ36af8xGdCvevi/E2czasw57mNLJ7eE44U8aY5OagcnW+RlpvfiLUwOWMjyg== X-Received: by 2002:a05:6a00:a8b:b0:4e1:52db:9e5c with SMTP id b11-20020a056a000a8b00b004e152db9e5cmr10743520pfl.38.1652568534268; Sat, 14 May 2022 15:48:54 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:5d8d:1dbb:ac83:9388]) by smtp.gmail.com with ESMTPSA id a14-20020a170902710e00b001613dfe1678sm2659683pll.273.2022.05.14.15.48.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 May 2022 15:48:53 -0700 (PDT) Date: Sat, 14 May 2022 15:48:49 -0700 From: Fangrui Song To: Nicholas Guriev Cc: Siddhesh Poyarekar , libc-alpha@sourceware.org Subject: Re: [PATCH v3] elf: Rewrite long RESOLVE_MAP macro to a debug friendly function Message-ID: <20220514224849.d7isxwcxnxoo3jhc@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2022 22:48:57 -0000 On 2022-05-14, Nicholas Guriev wrote: >On =D0=9F=D0=BD, 2022-05-09 at 19:08 +0530, Siddhesh Poyarekar wrote: >> Please use __always_inline instead, which adds the inline keyword as >> well as __attribute__ ((inline)).=C2=A0 That way gcc ensures that the >> function is *always* inlined. > >That is not necessary. My original intention was to improve the >debugging experience at this point. And the standard `inline` keyword >allows one to control optimizations with the -O flag. > Looks good to me, I think the always_inline here does not affect performance, as shown in my testing with a large PIE with many R_*_RELATIVE (function call overhead is larger with a non-R_*_RELATIVE). I will wait a bit and can push the commit in case Nicholas does not have write access. Reviewed-by: Fangrui Song