Clang documentation claims that attribute ((target(“XXX”))) is supported in clang, see http://clang.llvm.org/docs/AttributeReference.html#target-gnu-target But the semantic of the attribute is significantly different in Clang and GCC (see GCC documentation https://gcc.gnu.org/wiki/FunctionMultiVersioning). In short Clang allows to specify target CPU for a single function but GCC allows to specify set of functions optimized for different CPUs and generates dynamic dispatching code. Is it intentional difference in the semantic of the attribute or it is just missing feature that needs to be implemented?
Not exactly different, just limited - as the GCC wiki page mentions, GCC supported (& continues to support) the target attribute without the multiversioning feature. That’s all that Clang has implemented - you specify you want a certain function compiled for a certain architecture/feature/etc, and then it’s up to you how you dispatch to that function to ensure that you only call it when running in the right environment.
Implementing actual multiversioning (with the overloads, ifunc relocations/stub generation, etc) is not implemented currently and while I don’t know of anyone who has plans to, it’s certainly something that could be done (ie: the project isn’t philosophically opposed to the feature or anything).
> Implementing actual multiversioning (with the overloads, ifunc
> relocations/stub generation, etc) is not implemented currently and while
I
> don't know of anyone who has plans to, it's certainly something that
could
> be done (ie: the project isn't philosophically opposed to the feature or
> anything).
We are not? IMO creating tools for magically matching the target to
whatever the system currently runs on is not the job of the compiler.
*shrug* Seems like a reasonable feature that GCC offers and people use.
What would be the problem with it?
Do you want code emitted to magically call __cpuid() and match patterns
or whatever on it? This kind of logic sounds to be exactly like the
thing an application should be controlling.
>
> > > Implementing actual multiversioning (with the overloads, ifunc
> > > relocations/stub generation, etc) is not implemented currently and
while
> > I
> > > don't know of anyone who has plans to, it's certainly something that
> > could
> > > be done (ie: the project isn't philosophically opposed to the
feature or
> > > anything).
> >
> > We are not? IMO creating tools for magically matching the target to
> > whatever the system currently runs on is not the job of the compiler.
> >
>
> *shrug* Seems like a reasonable feature that GCC offers and people use.
> What would be the problem with it?
Do you want code emitted to magically call __cpuid() and match patterns
or whatever on it?
That's what GCC does here, so far as I know.
This kind of logic sounds to be exactly like the
thing an application should be controlling.
That's an option - if we surface the raw ifunc stuff, which I imagine we
would first before implementing the higher level function multiversioning.
But I'm not sure it adds a lot of value to have the application write that
code - but sure, could take a bit of a survey and see if function
multiversioning is used much/worth the compiler implementation complexity
over just implementing ifunc and letting the user figure it out from there.
shrug FWIW this is why I haven’t really implemented this side of things yet. I’m not convinced that the extra syntactic sugar around it is buying anyone anything, not even really convinced that the ifunc stuff in general is worth it, but not going to object if anyone else wants to implement it.
Thank you all for confirming that it is missing functionality in Clang. Indeed proper ifunc support should be a good first step for multiversioning support. Eric, are you working on ifunc support?
Multiversioning support will also needs name mangling enchantment to encode target attributes.
> This kind of logic sounds to be exactly like the
> thing an application should be controlling.
>
That's an option - if we surface the raw ifunc stuff, which I imagine we
would first before implementing the higher level function multiversioning.
ifunc again is a non-portable feature...
But I'm not sure it adds a lot of value to have the application write that
code - but sure, could take a bit of a survey and see if function
multiversioning is used much/worth the compiler implementation complexity
over just implementing ifunc and letting the user figure it out from there.
Most libraries that care just have function pointers they call and
initialise to the appropiate version. That's how they have been using
optimised assembler versions for specific targets for ages. I don't see
how this is different. More importantly, it gives users/developers
control over what happens, which is surprisingly often an issue.
> > This kind of logic sounds to be exactly like the
> > thing an application should be controlling.
> >
>
> That's an option - if we surface the raw ifunc stuff, which I imagine we
> would first before implementing the higher level function
multiversioning.
ifunc again is a non-portable feature...
Sure - but one that some users on platforms where it's available might want
to use. LLVM certainly isn't limited to implementing only a portable subset
of functionality available on all our current targets.
> But I'm not sure it adds a lot of value to have the application write
that
> code - but sure, could take a bit of a survey and see if function
> multiversioning is used much/worth the compiler implementation complexity
> over just implementing ifunc and letting the user figure it out from
there.
Most libraries that care just have function pointers they call and
initialise to the appropiate version. That's how they have been using
optimised assembler versions for specific targets for ages. I don't see
how this is different.
Well, ifunc means potentially reduced call overhead since it's no longer an
indirect call at least.
More importantly, it gives users/developers
control over what happens, which is surprisingly often an issue.
Sure, and none of these features would remove the users ability to drop
down to lower levels (multiversioning -> raw ifunc -> raw target
attribute/manual dispatch).
Thank you all for confirming that it is missing functionality in Clang.
Indeed proper ifunc support should be a good first step for multiversioning
support. Eric, are you working on ifunc support?
Nope, no one in the community is working on anything in this space at the
moment.