From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id BF4943835406 for ; Thu, 22 Apr 2021 09:02:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BF4943835406 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-2-EQ8R5KT1MRO7Y9odlF35xA-1; Thu, 22 Apr 2021 05:02:06 -0400 X-MC-Unique: EQ8R5KT1MRO7Y9odlF35xA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4384802B78; Thu, 22 Apr 2021 09:02:05 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-115-183.ams2.redhat.com [10.36.115.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6C91F5C1D5; Thu, 22 Apr 2021 09:02:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 13M922K31401484 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 11:02:02 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 13M921fZ1401483; Thu, 22 Apr 2021 11:02:01 +0200 Date: Thu, 22 Apr 2021 11:02:01 +0200 From: Jakub Jelinek To: "H.J. Lu" Cc: Martin Sebor , gcc-patches@gcc.gnu.org Subject: Re: [PATCH v4 2/2] x86: Add general_regs_only function attribute Message-ID: <20210422090201.GO1179226@tucnak> Reply-To: Jakub Jelinek References: <20210414223918.230495-1-hjl.tools@gmail.com> <20210414223918.230495-3-hjl.tools@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-List-Received-Date: Thu, 22 Apr 2021 09:02:10 -0000 On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote: > How about this? > > @item general_regs_only > @cindex @code{general_regs_only} function attribute, x86 > The @code{general_regs_only} function attribute informs the compiler > that the function uses only general purpose registers. When the > compiler inlines a function with the @code{always_inline} attribute, > target-specific compilation options may lead to inline failures. > The @code{general_regs_only} attribute, if applicable, can be used > together with the @code{always_inline} attribute to reduce inlining > failure. I don't really like this attribute. It is very specific to what you want to solve and doesn't address the general problem, that always_inline means different things in different code, and that is a problem for many targets, not just one. As has been written, in some cases it means inline always, error whenever it is called indirectly which can't be optimized into a direct call that can be inlined and error whenever the inlining fails for other reasons. Another case, e.g. in the glibc fortify wrappers, is inline always when the call is direct or an indirect call can be optimized into a direct call and error when the inlining fails, but support indirect calls without errors. Another case, which is most of the x86/aarch64/arm etc. intrinsics, is inline always unless there is a target mismatch (roughly what is actually implemented). Because from the always_inline attribute it is impossible to determine which one of those it is (for the indirect calls the rule could be gnu_inline extern inline means indirect calls are ok, anything else means indirect calls are bad), we need new syntax to distinguish those cases. general_regs_only attribute doesn't seem to be it, e.g. for the glibc fortify wrappers cases I don't see why we should forbid using floating point in such inlines. So IMHO we need some new attribute for one of those, or optional parameter to always_inline. For the intrinsic case, ideal would be if we could record which ISA flags (or more generally which options) are required and which are not. Either have some syntax where those would be explicitly specified in attribute (but frankly that would be a maintainance nightmare), or derive those from surrounding pragmas. Right now we have those wrapped in #ifndef __AVX2__ #pragma GCC push_options #pragma GCC target("avx2") #define __DISABLE_AVX2__ #endif /* __AVX2__ */ ... #ifdef __DISABLE_AVX2__ #undef __DISABLE_AVX2__ #pragma GCC pop_options #endif /* __DISABLE_AVX2__ */ The question is if the pragma GCC target right now behaves incrementally or not, whether #pragma GCC target("avx2") adds -mavx2 to options if it was missing before and nothing otherwise, or if it switches other options off. If it is incremental, we could e.g. try to use the second least significant bit of global_options_set.x_* to mean this option has been set explicitly by some surrounding #pragma GCC target. The normal tests - global_options_set.x_flag_whatever could still work fine because they wouldn't care if the option was explicit from anywhere (command line or GCC target or target attribute) and just & 2 would mean it was explicit from pragma GCC target; though there is the case of bitfields... And then the inlining decision could check the & 2 flags to see what is required and what is just from command line. Or we can have some other pragma GCC that would be like target but would have flags that are explicit (and could e.g. be more restricted, to ISA options only, and let those use in addition to #pragma GCC target. Jakub