On 4/12/21 7:03 PM, H.J. Lu wrote:
On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor <mse...@gmail.com> wrote:
On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
<richard.guent...@gmail.com> wrote:
On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with the always_inline
attribute may be ignored. On x86 targets, this attribute can be used on
integer functions to ignore target non-integer option mismatch.
I'm not sure I like such attribute but please adjust default_target_can_inline_p
accordingly (only few targets override this hook).
Richard.
Like this?
Thanks.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1ddafb3ff2c..44588566f2d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3187,6 +3187,14 @@ int S::interface (int) __attribute__ ((ifunc
("_ZN1S8resolverEv")));
Indirect functions cannot be weak. Binutils version 2.20.1 or higher
and GNU C Library version 2.11.1 are required to use this feature.
+@item inline_ignore_target
+@cindex @code{inline_ignore_target} function attribute
+The @code{inline_ignore_target} attribute on functions is used to
+inform the compiler that target specific option mismatch on functions
+with the @code{always_inline} attribute may be ignored. On x86 targets,
+this attribute can be used on integer functions to ignore target
+non-integer option mismatch.
+
@item interrupt
@itemx interrupt_handler
Many GCC back ends support attributes to indicate that a function is
I'm having a hard time understanding the description above (or
the attribute's name for that matter).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
has a testcase.
Thanks. My overall point is that GCC users should be able to answer
these questions from reading the documentation of the attribute in
the manual.
The inline_ignore_target function attribute informs the compiler
that "target specific option mismatch on functions with the
@code{always_inline} attribute" may be ignored.
What does "target specific option mismatch" mean? Is it a mismatch
This refers to the message from GCC:
/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ia32intrin.h:112:1:
error: inlining failed in call to ‘always_inline’ ‘__rdtsc’: target
specific option mismatch
112 | __rdtsc (void)
| ^~~~~~~
But what exactly does the target-specific option refer to, and what
does it fail to match? Presumably, it refers to the option in
the attribute on the function declaration in the PR:
__attribute__ ((target("general-regs-only")))
and the inability to use the rdtsc instruction with a GPR.
But unless the error either mentions the -mgeneral-regs-only option
by name or is followed by a note that points to the option in
the function declaration, the words "target specific option" alone
aren't enough to understand what the error means, and the text in
the manual doesn't help.
I would suggest to improve the message and the manual.
between target-specific optimization options added to a function by
attribute optimize vs other target-specific optimization options of
the function callers (e.g., added to them by another instance of
attribue optimize, or by #pragma GCC optimize), into which a function
with the attribute may be inlined, and where the conflict between
the two sets of options needs to be reconciled? And if so, should
It is added to support integer functions with always_inline attribute.
Currently x86 integer functions with always_inline attribute fail to
compile when caller has general-regs-only target attribute and
SSE is enabled by default.
Thanks. I would suggest to also explain this in the manual.
it be provided as a generic attribute for all targets?
I'm still wondering if this should be a generic attribute. Besides
x86, I see -mgeneral-regs-only also provided by ARM and Aarch64, so
I would expect the attribute to be useful to those targets as well,
and to all other targets that add the option or one like it in
the future. I believe it's better for portability to add a generic
attribute even if it's not universally supported, than a target-
specific one.
Different targets can have different sets of conflict target specific
options.
Also, what's "integer functions" supposed to mean? Functions that
return integers?
An integer function can be compiled with -mgeneral-regs-only.
I don't think that answers my question. It sounds like a property
of something you call an /integer function/. My question is: what
is [the definition of] an integer function? In other words, how can
one tell whether or not an arbitrary function is an integer function?
The manual should either define the term /integer function/ or it
should describe what it means so that readers won't have to ask this
question. If the definition is "an integer function is one that can
be compiled without error with -mgeneral-regs-only" then then that's
what the manual should say (although I'd hope for more detail and
clarity than that.)
This new attribute seems sufficiently specialized that I think
the description ought to be expanded to make it clearer what it's
for, why it's needed, and when and how to use it. Adding an example
or two might help, as would using more precise terminology.
Separately, seeing no tests for it in the patch, I wonder how
There are 2 existing tests: gcc.target/i386/pr99744-1.c and
gcc.target/i386/pr99744-2.c. If we want to go with this approach,
I will add inline_ignore_target to all x86 integer intrinsics with
tests.
I don't have much of an opinion on the approach itself (adding
an attribute to avoid the error). I'm trying to help improve
the usability of the feature to prevent gaps (underspecified
aspects) in new attributes that are then hard to sort out after
the attribute has been introduced. This affects GCC users as
well as developers and users of GCC-compatible compilers, and
eventually also GCC devs as bug reports against GCC are open by
users of other compilers that, in the absence of an unambiguous
interpretetation of both the documentation and the behavior
provide subtly different semantics than GCC.
the new attribute interacts (or should interact) with other
attributes or other kinds of functions than the ones it's tested
with. For example, what happens when the attribute is added to
a function that's not declared inline, or that's declared with
the noinline attribute.
This attribute should be used together with always_inline attribute.
I would suggest to both document this constraint and issue an error
when it's not used this way, along with a test case to verify it.
Martin
