[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
> wrote:
> > > > 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.

- Dave


>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151208/4180e892/attachment.html>


More information about the cfe-dev mailing list