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

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

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
>

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>