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

[Rafael Espíndola via llvm-dev]

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
>