This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Function multiversioning question


On 10/25/18 7:13 AM, Martin Reinecke wrote:

This creates a nasty asymmetry in the sense that gcc's own optimizations
will be able to use all target features (because the compiler knows that
it is OK to use specific features like AVX instructions) whereas the
user has no way to hand-optimize where this becomes necessary. At least
not using this nice mechanism.

They can, just not based on preprocessor macros.

I was thinking about decisions at compile time (along the lines of "ah,
I'm in the AVX-specific version of the function, therefore I will call
AVX intrinsics"), and I don't see a way to make them without access to
macros.
At runtime this is of course possible.

Since each of the clones has a target attribute attached to it there
should be a way to query that attribute at compile time.  GCC 9
provides a __builtin_has_attribute intrinsic for simple attribute
introspection so in principle it could be used for this.  One caveat
is that the clones only get created by the middle-end so evaluating
the attribute query would have to be deferred until then (right now
it's evaluated during parsing).  As a result, it would no longer
evaluate to a constant expression in this form.  Another challenge
is how to distinguish the clones from the default function so that

  __builtin_has_attribute (foo, target ("avx2"))

didn't refer to the default foo as it does now.  It might need some
special syntax to refer to the current function.

If this is something you would would useful please open a request
n Bugzilla.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]