[cfe-dev] __attribute__ ((target("XXX"))) semantic in clang and gcc
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Tue Dec 8 13:00:47 PST 2015
On Tue, Dec 8, 2015 at 12:54 PM, Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Tue, Dec 08, 2015 at 12:41:57PM -0800, David Blaikie wrote:
> > On Tue, Dec 8, 2015 at 12:18 PM, Joerg Sonnenberger via cfe-dev <
> > cfe-dev at lists.llvm.org> wrote:
> > > On Tue, Dec 08, 2015 at 09:38:58AM -0800, David Blaikie via cfe-dev
> > > > Implementing actual multiversioning (with the overloads, ifunc
> > > > relocations/stub generation, etc) is not implemented currently and
> > > 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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev