[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:46:56 PST 2015


On Wed, Dec 9, 2015 at 12:34 AM, Dmitry Polukhin <dmitry.polukhin at gmail.com>
wrote:

> 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.

- Dave


>
> Multiversioning support will also needs name mangling enchantment to
> encode target attributes.
>
> On Wed, Dec 9, 2015 at 12:42 AM, Eric Christopher via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Dec 8, 2015 at 1:00 PM David Blaikie via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> 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.
>>>
>>>
>> *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.
>>
>> -eric
>>
>>
>>> - Dave
>>>
>>>
>>>>
>>>> Joerg
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> 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/20151209/c24bce0a/attachment.html>


More information about the cfe-dev mailing list