On 4/21/21 2:58 PM, H.J. Lu wrote:
On Wed, Apr 21, 2021 at 10:09 AM Martin Sebor <mse...@gmail.com> wrote:
On 4/14/21 4:39 PM, H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu <hjl.to...@gmail.com>
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.)
That is correct.
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.
This is what GCC does today:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
Yes, that's the rather obscure error I think I commented on before
and suggested should be improved. Based on r99744-3.c I don't think
this has changed in the improved patch.
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
How about this
@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. It
can be used together with the @code{always_inline} attribute to avoid
inlining failure when there is a mismatch in compiler vector options.
Without an article the part "that functions use only general purpose
registers" is unclear and/or grammatically incorrect. What functions?
If the function the attribute is applied to, it needs an article, e.g.,
"the function" or "a function", and singular. (Otherwise it could be
read as talking about the functions called from the one with
the attribute, or some other functions altogether).
I tried to correct that above but, if you prefer, the following would
be closer to your phrasing but more correct/accurate:
The @code{general_regs_only} function attribute informs
the compiler that the function uses only general purpose
registers.
I don't understand what the second sentence is trying to say, and
without a better error message for the problem in r99744, I suspect
few users will either. I am suggesting to explain in the text you
are adding, under what conditions inlining might fail without
the attribute, and what effect the attribute has on the function
that prevents the inlining failure.
(If we can't explain what the effect is then I wonder why
the attribute is being added at all instead of teaching GCC to
always behave as if the attribute were there when its absence
would otherwise lead to an error.)
Martin
