[llvm-dev] RFC: __attribute__((ifunc("resolver")) representation in LLVM IR
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 18 17:47:11 PST 2015
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>
> I would probably go with 2.
> 3 is particularly undesirable as it make the ifunc really hard to
> differentiate from an alias.
> 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.
> > 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
> > `@gnu_indirect_function` in ELF reader/writer/target asm parser. This
> RFC is
> > looking for thoughts and suggestions about representation of ifunc in
> > IR.
> > Alternatives for ifunc representation:
> > 1. Add a boolean flag isIFunc to`GlobalAlias`
> > From implementation perspective ifunc is very close to a function alias
> > points to resolver function as a target. During asm emissions
> > `@gnu_indirect_function` symbol attribute is added. In printed LLVM it
> > look like this:
> > `@foo = alias ifunc i32 (i32), bitcast (i64 ()* @foo_ifunc to i32
> > Pros:
> > - minimal changes LLVM code base
> > Cons:
> > - ifunc is not really an alias, if some code passes through alias and
> > 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
> > `@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
> > and inhibit optimizations in LLVM for such alias (it is always wrong to
> > 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.
> > got feedback that I should use second approach instead + request to write
> > RFC about this IR extension for broader discussion. I'm convinced that
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev