From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id 807E13892451 for ; Wed, 21 Apr 2021 17:09:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 807E13892451 Received: by mail-qk1-x72e.google.com with SMTP id v7so15440467qkj.13 for ; Wed, 21 Apr 2021 10:09:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wEyPGOZ9p8AfAw2ySgsFN2PzWRhzUpnJCfySHSqgeCA=; b=ERfqt68g31717F9YIjp9hw+PrIqYFtxTgR75O4AMjr1OCk3ECG/wMqZhCou7Xrj29T Qs5h0EfpdUaz/3J61Lgmv3+fgk0UdKCiJgIrEn28yluKiFSW/0kIz7bmPj/eiqMuT51Z dZhjBrSkUD7lpF1ToT0Hb25fbWyRzxQjF/A4+jksBjj61N83oMEvMZ1ZCLybUkmuu5yu lHeaopuhiuIvgViitt9MpTQpiQfteSA9s9aW4rz62P/Euc8kl4v+boHao5RRRZWP8WzD Zte4TYYFRh3OuFyslkgn66O9RpOmnNSL68gTA/MDx5xhg5rANkeovHCqXYOeC5oi2inq AAaQ== X-Gm-Message-State: AOAM530NHofceOeHLp0tQvXIKJCBVni7of9nLpNCSuw6rxyvQ6dTpugk nJDhM8zDxAl3YY8z54qgrIg= X-Google-Smtp-Source: ABdhPJy+AYes7IZeCjyqDXGGuwXudS9Waz520+vTgpANftgXmT5zqOcFgKLWL02mgVEx2Oj/X7qpLg== X-Received: by 2002:a05:620a:214f:: with SMTP id m15mr23119699qkm.419.1619024946106; Wed, 21 Apr 2021 10:09:06 -0700 (PDT) Received: from [192.168.0.41] (71-218-23-248.hlrn.qwest.net. [71.218.23.248]) by smtp.gmail.com with ESMTPSA id t21sm2728445qkj.32.2021.04.21.10.09.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Apr 2021 10:09:05 -0700 (PDT) Subject: Re: [PATCH v4 2/2] x86: Add general_regs_only function attribute To: "H.J. Lu" , gcc-patches@gcc.gnu.org Cc: Uros Bizjak , Jakub Jelinek , Bernhard Reutner-Fischer , Richard Biener References: <20210414223918.230495-1-hjl.tools@gmail.com> <20210414223918.230495-3-hjl.tools@gmail.com> From: Martin Sebor Message-ID: Date: Wed, 21 Apr 2021 11:09:04 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20210414223918.230495-3-hjl.tools@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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: Wed, 21 Apr 2021 17:09:08 -0000 On 4/14/21 4:39 PM, H.J. Lu wrote: > commit 87c753ac241f25d222d46ba1ac66ceba89d6a200 > Author: H.J. Lu > Date: Fri Aug 21 09:42:49 2020 -0700 > > x86: Add target("general-regs-only") function attribute > > is incomplete since it is impossible to call integer intrinsics from > a function with general-regs-only target attribute. > > 1. Add general_regs_only function attribute to inform the compiler that > functions use only general purpose registers. When making inlining > decisions on such functions, non-GPR compiler options are excluded. > 2. Add general_regs_only attribute to x86 intrinsics which use only > general purpose registers. > ... > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -7066,6 +7066,11 @@ On x86 targets, the @code{fentry_section} attribute sets the name > of the section to record function entry instrumentation calls in when > enabled with @option{-pg -mrecord-mcount} > > +@item general_regs_only > +@cindex @code{general_regs_only} function attribute, x86 > +The @code{general_regs_only} attribute on functions is used to > +inform the compiler that functions use only general purpose registers. I'll just reiterate basically the same comment as before: it's not clear from the very brief description above what the requirements are for using the attribute. I'm guessing it can be applied to any function (inline or otherwise) but only has any effect when the function is actually inlined and otherwise doesn't constrain what the function can do. (Whatever the constraints are, I think the manual should spell them out, and likewise for its effects.) Similarly it's not clear what should be expected when the function does use some other register. Ideally, I think GCC would check and issue a nice error message whether or not the function is inlined or called. I suspect that might only be possible for inline functions that are actually called and for which the back end must emit code. Other than that, I'd suggest to improve the phrasing a bit: The @code{general_regs_only} function attribute indicates that the function uses only general purpose registers... [text explaining constraints and errors follows]. Martin