<div dir="ltr">From what I see putting ifunc into separate list is better aligned with LLVM design so I prepared CL that does it in <a href="http://reviews.llvm.org/D15525">http://reviews.llvm.org/D15525</a> Amount of changes is about 3-5x in comparison with using bool flag for GlobalAlias (first patchset).<div><br></div><div>Having all global objects in single list does make some sense to me and iterators could skip objects of uninteresting types. But I think such change is much bigger and much deeper. So I'm not sure that the result worse such major change in code base.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 23, 2015 at 6:21 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If changing nothing else I would probably go with another list since<br>
that is what is done for functions/variables/aliases.<br>
<br>
Having said that, more than once I wished we had an easy way to<br>
iterate all GlobalValues or all GrobalObjects. Any thoughts on the<br>
tradeoff having a single list with pointer to the start of each sub<br>
list? Something like<br>
<br>
Func1 <-> Func2 <-> Var1 <-> Var2 <-> Alias1 <-> Alias2 <-> IFunc1 <-> Ifunc2<br>
<br>
and keep FirstFunc, FirstVar, FirstAlias and FirstIFunc pointers.<br>
<br>
One place where having another list might be a bit annoying is the<br>
symbol iterator of IRObjectFile.<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 22 December 2015 at 08:23, Dmitry Polukhin <<a href="mailto:dmitry.polukhin@gmail.com">dmitry.polukhin@gmail.com</a>> wrote:<br>
> I start prototyping second approach that makes ifunc new type of<br>
> GlobalValue. And I would like to reconfirm how much we would like to share<br>
> between aliases and ifuncs. For example, should Module have separate lists<br>
> of aliases and ifuncs or they both should be in the same list of indirect<br>
> symbols? If ifuncs and aliases are in separate lists, common base class is<br>
> less useful and I found myself duplicating aliases code to support ifunc<br>
> (that is relatively small code but here and there). On the other hand if I<br>
> rename aliases to indirect symbols, all places that work with aliases will<br>
> have to be updated to support this renaming and sometimes check if the<br>
> object in the list is an alias or ifunc (i.e. it becomes close to first<br>
> approach + bunch renaming). So I would like to hear community input on how<br>
> separate aliases and ifuncs should be.<br>
><br>
> On Mon, Dec 21, 2015 at 12:19 PM, Dmitry Polukhin<br>
> <<a href="mailto:dmitry.polukhin@gmail.com">dmitry.polukhin@gmail.com</a>> wrote:<br>
>><br>
>> I would like to support __attribute__((target)) later so ifunc won't be<br>
>> opaque for compiler generated dispatchers.<br>
>><br>
>> Thank you all for the feedback!<br>
>><br>
>> On Sat, Dec 19, 2015 at 8:49 AM, Eric Christopher via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> I think 2 is the only reasonable answer. And to answer Reid's comment:<br>
>>> yes, it might be nice if we could look through it for compiler generated<br>
>>> resolver functions - something to keep in mind for the future.<br>
>>><br>
>>><br>
>>> On Fri, Dec 18, 2015, 5:47 PM Reid Kleckner via llvm-dev<br>
>>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>><br>
>>>> Are you going to have to teach LLVM how to look through ifuncs, or is it<br>
>>>> OK if they are totally opaque?<br>
>>>><br>
>>>> For example, with __attribute__((target)), you might have one<br>
>>>> target-specialized function call another. Is it important that we be able to<br>
>>>> optimize away the dynamic dispatch there or not?<br>
>>>><br>
>>>> Either way, I think a new IR construct is the way to go.<br>
>>>><br>
>>>> On Fri, Dec 18, 2015 at 11:44 AM, Rafael Espíndola<br>
>>>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>><br>
>>>>> 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>
>>>>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>> > Hi Everyone,<br>
>>>>> ><br>
>>>>> > I would like to implement GCC ifunc attribute support in Clang and<br>
>>>>> > LLVM. At<br>
>>>>> > the moment Clang ignores the attribute with a warning. On LLVM IR<br>
>>>>> > level<br>
>>>>> > there is no support for ifunc. But there is some support for ELF<br>
>>>>> > symbol type<br>
>>>>> > `@gnu_indirect_function` in ELF reader/writer/target asm parser. This<br>
>>>>> > RFC is<br>
>>>>> > looking for thoughts and suggestions about representation of ifunc in<br>
>>>>> > 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<br>
>>>>> > alias that<br>
>>>>> > points to resolver function as a target. During asm emissions<br>
>>>>> > `@gnu_indirect_function` symbol attribute is added. In printed LLVM<br>
>>>>> > it could<br>
>>>>> > look like this:<br>
>>>>> ><br>
>>>>> > `@foo = alias ifunc i32 (i32), bitcast (i64 ()* @foo_ifunc to i32<br>
>>>>> > (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<br>
>>>>> > 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<br>
>>>>> > 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<br>
>>>>> > proposal add<br>
>>>>> > `@gnu_indirect_function` symbol attribute. In printed LLVM it could<br>
>>>>> > 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<br>
>>>>> > 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<br>
>>>>> > detect<br>
>>>>> > and inhibit optimizations in LLVM for such alias (it is always wrong<br>
>>>>> > to use<br>
>>>>> > resolver instead of ifunc they even have different function type)<br>
>>>>> > - asm statement in general not very reliable mechanism in general,<br>
>>>>> > 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<br>
>>>>> > <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<br>
>>>>> > write<br>
>>>>> > RFC about this IR extension for broader discussion. I'm convinced<br>
>>>>> > that the<br>
>>>>> > second approach is cleaner and if there is no better suggestion or<br>
>>>>> > push<br>
>>>>> > back, I'm going to prepare such patch. Third approach mostly added<br>
>>>>> > 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<br>
>>>>> > <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>
>>>>> > _______________________________________________<br>
>>>>> > LLVM Developers mailing list<br>
>>>>> > <a href="mailto:llvm-dev@lists.llvm.org">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">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>
>>>> _______________________________________________<br>
>>>> LLVM Developers mailing list<br>
>>>> <a href="mailto:llvm-dev@lists.llvm.org">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>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org">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>
><br>
</div></div></blockquote></div><br></div>