<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 6:39 AM, Joerg Sonnenberger via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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"><span class="">On Fri, Dec 18, 2015 at 09:17:17AM +0000, Dmitry Polukhin via llvm-commits wrote:<br>
> Just for the sake of completeness, there is a way to avoid IR extension<br>
> - it is possible to emit global asm statement like<br>
>    `__asm__ (".type resolver_alias_name, @gnu_indirect_function")`<br>
> and avoid IR extension but I didn't seriously consider this path.<br>
<br>
</span>Why not? Let me put it another way: what is the advantage of making the<br>
intermediate layers aware of ifuncs? Can they provide better<br>
optimisations? Can they diagnose any potential bugs?</blockquote><div><br></div><div>One possible optimization:<br><br>say you have a target specific function that calls a generic function that in turn calls an ifunc function<br>with ifunc as a first-class construct you can potentially inline both calls into the target specific outer function - inline the generic one, and in doing so, observe that the resolver function would produce a constant result (would have to teach the inliner about a cpuid intrinsic of some sort) & thus lower the call-to-ifunc with a direct call, then inline that call, etc.<br><br>- David </div></div></div></div>