<div dir="ltr">I start prototyping second approach that makes ifunc new type of GlobalValue. And I would like to reconfirm how much we would like to share between aliases and ifuncs. For example, should Module have separate lists of aliases and ifuncs or they both should be in the same list of indirect symbols? If ifuncs and aliases are in separate lists, common base class is less useful and I found myself duplicating aliases code to support ifunc (that is relatively small code but here and there). On the other hand if I rename aliases to indirect symbols, all places that work with aliases will have to be updated to support this renaming and sometimes check if the object in the list is an alias or ifunc (i.e. it becomes close to first approach + bunch renaming). So I would like to hear community input on how separate aliases and ifuncs should be.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 12:19 PM, Dmitry Polukhin <span dir="ltr"><<a href="mailto:dmitry.polukhin@gmail.com" target="_blank">dmitry.polukhin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would like to support __attribute__((target)) later so ifunc won't be <span style="font-size:12.8px">opaque for compiler generated dispatchers.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thank you all for the feedback!</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 8:49 AM, Eric Christopher via llvm-dev <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"><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><div><div>
<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" target="_blank">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>
</div></div><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>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>