[llvm-dev] RFC: __attribute__((ifunc("resolver")) representation in LLVM IR

[Dmitry Polukhin via llvm-dev]

Bring this RFC up after long holiday break. I need more feedback on ifunc
representation in llvm.

Patch that accumulates current feedback (i.e. ifunc is a new type of
GlobalValue) http://reviews.llvm.org/D15525
If there is no high level feedback, please contribute to review.

On Thu, Dec 24, 2015 at 5:42 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com>
wrote:

> From what I see putting ifunc into separate list is better aligned with
> LLVM design so I prepared CL that does it in
> http://reviews.llvm.org/D15525 Amount of changes is about 3-5x in
> comparison with using bool flag for GlobalAlias (first patchset).
>
> Having all global objects in single list does make some sense to me and
> iterators could skip objects of uninteresting types. But I think such
> change is much bigger and much deeper. So I'm not sure that the result
> worse such major change in code base.
>
> On Wed, Dec 23, 2015 at 6:21 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> If changing nothing else I would probably go with another list since
>> that is what is done for functions/variables/aliases.
>>
>> Having said that, more than once I wished we had an easy way to
>> iterate all GlobalValues or all GrobalObjects. Any thoughts on the
>> tradeoff having a single list with pointer to the start of each sub
>> list? Something like
>>
>> Func1 <-> Func2 <-> Var1 <-> Var2 <-> Alias1 <-> Alias2 <-> IFunc1 <->
>> Ifunc2
>>
>> and keep FirstFunc, FirstVar, FirstAlias and FirstIFunc pointers.
>>
>> One place where having another list might be a bit annoying is the
>> symbol iterator of IRObjectFile.
>>
>> Cheers,
>> Rafael
>>
>>
>> On 22 December 2015 at 08:23, Dmitry Polukhin <dmitry.polukhin at gmail.com>
>> wrote:
>> > I start prototyping second approach that makes ifunc new type of
>> > GlobalValue. And I would like to reconfirm how much we would like to
>> share
>> > between aliases and ifuncs. For example, should Module have separate
>> lists
>> > of aliases and ifuncs or they both should be in the same list of
>> indirect
>> > symbols? If ifuncs and aliases are in separate lists, common base class
>> is
>> > less useful and I found myself duplicating aliases code to support ifunc
>> > (that is relatively small code but here and there). On the other hand
>> if I
>> > rename aliases to indirect symbols, all places that work with aliases
>> will
>> > have to be updated to support this renaming and sometimes check if the
>> > object in the list is an alias or ifunc (i.e. it becomes close to first
>> > approach + bunch renaming). So I would like to hear community input on
>> how
>> > separate aliases and ifuncs should be.
>> >
>> > On Mon, Dec 21, 2015 at 12:19 PM, Dmitry Polukhin
>> > <dmitry.polukhin at gmail.com> wrote:
>> >>
>> >> I would like to support __attribute__((target)) later so ifunc won't be
>> >> opaque for compiler generated dispatchers.
>> >>
>> >> Thank you all for the feedback!
>> >>
>> >> On Sat, Dec 19, 2015 at 8:49 AM, Eric Christopher via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >>>
>> >>> I think 2 is the only reasonable answer. And to answer Reid's comment:
>> >>> yes, it might be nice if we could look through it for compiler
>> generated
>> >>> resolver functions - something to keep in mind for the future.
>> >>>
>> >>>
>> >>> On Fri, Dec 18, 2015, 5:47 PM Reid Kleckner via llvm-dev
>> >>> <llvm-dev at lists.llvm.org> wrote:
>> >>>>
>> >>>> Are you going to have to teach LLVM how to look through ifuncs, or
>> is it
>> >>>> OK if they are totally opaque?
>> >>>>
>> >>>> For example, with __attribute__((target)), you might have one
>> >>>> target-specialized function call another. Is it important that we be
>> able to
>> >>>> optimize away the dynamic dispatch there or not?
>> >>>>
>> >>>> Either way, I think a new IR construct is the way to go.
>> >>>>
>> >>>> On Fri, Dec 18, 2015 at 11:44 AM, Rafael Espíndola
>> >>>> <llvm-dev at lists.llvm.org> wrote:
>> >>>>>
>> >>>>> I would probably go with 2.
>> >>>>>
>> >>>>> 3 is particularly undesirable as it make the ifunc really hard to
>> >>>>> differentiate from an alias.
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Rafael
>> >>>>>
>> >>>>>
>> >>>>> On 18 December 2015 at 13:44, Dmitry Polukhin via llvm-dev
>> >>>>> <llvm-dev at lists.llvm.org> wrote:
>> >>>>> > Hi Everyone,
>> >>>>> >
>> >>>>> > I would like to implement GCC ifunc attribute support in Clang and
>> >>>>> > LLVM. At
>> >>>>> > the moment Clang ignores the attribute with a warning. On LLVM IR
>> >>>>> > level
>> >>>>> > there is no support for ifunc. But there is some support for ELF
>> >>>>> > symbol type
>> >>>>> > `@gnu_indirect_function` in ELF reader/writer/target asm parser.
>> This
>> >>>>> > RFC is
>> >>>>> > looking for thoughts and suggestions about representation of
>> ifunc in
>> >>>>> > LLVM
>> >>>>> > IR.
>> >>>>> >
>> >>>>> > Alternatives for ifunc representation:
>> >>>>> >
>> >>>>> > 1. Add a boolean flag isIFunc to`GlobalAlias`
>> >>>>> > From implementation perspective ifunc is very close to a function
>> >>>>> > alias that
>> >>>>> > points to resolver function as a target. During asm emissions
>> >>>>> > `@gnu_indirect_function` symbol attribute is added. In printed
>> LLVM
>> >>>>> > it could
>> >>>>> > look like this:
>> >>>>> >
>> >>>>> > `@foo = alias ifunc i32 (i32), bitcast (i64 ()* @foo_ifunc to i32
>> >>>>> > (i32)*)`
>> >>>>> >
>> >>>>> > Pros:
>> >>>>> > - minimal changes LLVM code base
>> >>>>> >
>> >>>>> > Cons:
>> >>>>> > - ifunc is not really an alias, if some code passes through alias
>> and
>> >>>>> > starts
>> >>>>> > using resolver function instead of ifunc, it is always an error
>> >>>>> > - in particular in my prototype I had to add weak linkage to
>> inhibit
>> >>>>> > optimizations (it prevents them because LLVM assumes that linker
>> >>>>> > could
>> >>>>> > change the symbol but it could be fixed without changing linkage)
>> >>>>> >
>> >>>>> > 2. Extract common parts for alias and ifunc into a base class
>> >>>>> > Both alias and ifunc will be derived classes. Similar to first
>> >>>>> > proposal add
>> >>>>> > `@gnu_indirect_function` symbol attribute. In printed LLVM it
>> could
>> >>>>> > look
>> >>>>> > like:
>> >>>>> >
>> >>>>> > `@foo = ifunc i32 (i32), i64 ()* @foo_ifunc`
>> >>>>> >
>> >>>>> > Pros:
>> >>>>> > - no confusion for existing code
>> >>>>> > - cleaner from design perspective
>> >>>>> >
>> >>>>> > Cons:
>> >>>>> > - Add new type of Global i.e. more textual changes
>> >>>>> > - Some potential code duplication (need prototyping to estimate)
>> >>>>> >
>> >>>>> > 3. Emit global asm statement from Clang
>> >>>>> > Generate global asm statement like `__asm__ (".type
>> >>>>> > resolver_alias_name,
>> >>>>> > @gnu_indirect_function")` in Clang for alias generated for
>> resolver
>> >>>>> > function.
>> >>>>> >
>> >>>>> > Pros:
>> >>>>> > - (almost?) no changes in LLVM
>> >>>>> >
>> >>>>> > Cons:
>> >>>>> > - ifunc is not marked in LLVM IR at all so some hacks are
>> required to
>> >>>>> > detect
>> >>>>> > and inhibit optimizations in LLVM for such alias (it is always
>> wrong
>> >>>>> > to use
>> >>>>> > resolver instead of ifunc they even have different function type)
>> >>>>> > - asm statement in general not very reliable mechanism in general,
>> >>>>> > highly
>> >>>>> > depends on expected asm generated by compiler
>> >>>>> > - using low-level platform dependent information in Clang
>> >>>>> >
>> >>>>> > I prototyped first approach, changes in
>> >>>>> > http://reviews.llvm.org/D15525. But
>> >>>>> > got feedback that I should use second approach instead + request
>> to
>> >>>>> > write
>> >>>>> > RFC about this IR extension for broader discussion. I'm convinced
>> >>>>> > that the
>> >>>>> > second approach is cleaner and if there is no better suggestion or
>> >>>>> > push
>> >>>>> > back, I'm going to prepare such patch. Third approach mostly added
>> >>>>> > for
>> >>>>> > completeness.
>> >>>>> >
>> >>>>> > References:
>> >>>>> > - GCC ifunc documentation
>> >>>>> >
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>> >>>>> > - IFUNC low-level technical details
>> >>>>> > http://www.airs.com/blog/archives/403
>> >>>>> >
>> >>>>> > Thanks,
>> >>>>> > Dmitry Polukhin
>> >>>>> > --
>> >>>>> > Software Engineer
>> >>>>> > Intel Compiler Team
>> >>>>> >
>> >>>>> >
>> >>>>> > _______________________________________________
>> >>>>> > LLVM Developers mailing list
>> >>>>> > llvm-dev at lists.llvm.org
>> >>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>>> >
>> >>>>> _______________________________________________
>> >>>>> LLVM Developers mailing list
>> >>>>> llvm-dev at lists.llvm.org
>> >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> LLVM Developers mailing list
>> >>>> llvm-dev at lists.llvm.org
>> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> LLVM Developers mailing list
>> >>> llvm-dev at lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160111/1e3346f5/attachment.html>