<p dir="ltr">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. </p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 18, 2015, 5:47 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Are you going to have to teach LLVM how to look through ifuncs, or is it OK if they are totally opaque?<div><br></div><div>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?</div><div><br></div><div>Either way, I think a new IR construct is the way to go.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 11:44 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would probably go with 2.<br>
<br>
3 is particularly undesirable as it make the ifunc really hard to<br>
differentiate from an alias.<br>
<br>
Cheers,<br>
Rafael<br>
<br>
<br>
On 18 December 2015 at 13:44, Dmitry Polukhin via llvm-dev<br>
<div><div><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi Everyone,<br>
><br>
> I would like to implement GCC ifunc attribute support in Clang and LLVM. At<br>
> the moment Clang ignores the attribute with a warning. On LLVM IR level<br>
> there is no support for ifunc. But there is some support for ELF symbol type<br>
> `@gnu_indirect_function` in ELF reader/writer/target asm parser. This RFC is<br>
> looking for thoughts and suggestions about representation of ifunc in LLVM<br>
> IR.<br>
><br>
> Alternatives for ifunc representation:<br>
><br>
> 1. Add a boolean flag isIFunc to`GlobalAlias`<br>
> From implementation perspective ifunc is very close to a function alias that<br>
> points to resolver function as a target. During asm emissions<br>
> `@gnu_indirect_function` symbol attribute is added. In printed LLVM it could<br>
> look like this:<br>
><br>
> `@foo = alias ifunc i32 (i32), bitcast (i64 ()* @foo_ifunc to i32 (i32)*)`<br>
><br>
> Pros:<br>
> - minimal changes LLVM code base<br>
><br>
> Cons:<br>
> - ifunc is not really an alias, if some code passes through alias and starts<br>
> using resolver function instead of ifunc, it is always an error<br>
> - in particular in my prototype I had to add weak linkage to inhibit<br>
> optimizations (it prevents them because LLVM assumes that linker could<br>
> change the symbol but it could be fixed without changing linkage)<br>
><br>
> 2. Extract common parts for alias and ifunc into a base class<br>
> Both alias and ifunc will be derived classes. Similar to first proposal add<br>
> `@gnu_indirect_function` symbol attribute. In printed LLVM it could look<br>
> like:<br>
><br>
> `@foo = ifunc i32 (i32), i64 ()* @foo_ifunc`<br>
><br>
> Pros:<br>
> - no confusion for existing code<br>
> - cleaner from design perspective<br>
><br>
> Cons:<br>
> - Add new type of Global i.e. more textual changes<br>
> - Some potential code duplication (need prototyping to estimate)<br>
><br>
> 3. Emit global asm statement from Clang<br>
> Generate global asm statement like `__asm__ (".type resolver_alias_name,<br>
> @gnu_indirect_function")` in Clang for alias generated for resolver<br>
> function.<br>
><br>
> Pros:<br>
> - (almost?) no changes in LLVM<br>
><br>
> Cons:<br>
> - ifunc is not marked in LLVM IR at all so some hacks are required to detect<br>
> and inhibit optimizations in LLVM for such alias (it is always wrong to use<br>
> resolver instead of ifunc they even have different function type)<br>
> - asm statement in general not very reliable mechanism in general, highly<br>
> depends on expected asm generated by compiler<br>
> - using low-level platform dependent information in Clang<br>
><br>
> I prototyped first approach, changes in <a href="http://reviews.llvm.org/D15525" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15525</a>. But<br>
> got feedback that I should use second approach instead + request to write<br>
> RFC about this IR extension for broader discussion. I'm convinced that the<br>
> second approach is cleaner and if there is no better suggestion or push<br>
> back, I'm going to prepare such patch. Third approach mostly added for<br>
> completeness.<br>
><br>
> References:<br>
> - GCC ifunc documentation<br>
> <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html</a><br>
> - IFUNC low-level technical details <a href="http://www.airs.com/blog/archives/403" rel="noreferrer" target="_blank">http://www.airs.com/blog/archives/403</a><br>
><br>
> Thanks,<br>
> Dmitry Polukhin<br>
> --<br>
> Software Engineer<br>
> Intel Compiler Team<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>