llvm dev - Dec 2015 - RFC: __attribute__((ifunc("resolver")) representation in LLVM IR

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151218/0dc02fb7/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151219/73216d63/attachment.html>

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/20151221/b09ae85e/attachment.html>