[cfe-dev] __attribute__ ((target("XXX"))) semantic in clang and gcc

David Blaikie via cfe-dev cfe-dev at lists.llvm.org
Wed Dec 9 07:45:58 PST 2015


On Wed, Dec 9, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, Dec 08, 2015 at 01:00:47PM -0800, David Blaikie wrote:
> > > 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).

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151209/7542aa15/attachment.html>


More information about the cfe-dev mailing list