[cfe-dev] Using IFUNC with template functions

[Joerg Sonnenberger via cfe-dev]

On Thu, Nov 19, 2020 at 10:10:41AM +0000, David Chisnall via cfe-dev wrote:
> On 18/11/2020 20:04, Joerg Sonnenberger via cfe-dev wrote:
> > On Wed, Nov 18, 2020 at 06:12:58PM +0000, David Chisnall via cfe-dev wrote:
> > > I'd suggest extending the ifunc attribute parser to accept <> at the end of
> > > the identifier for the resolver to signify template arguments and require
> > > that the resolver takes the same template arguments as the function itself.
> > I'd suggest a different direction. I've mentioned a couple of times that
> > having a builtin for obtaining the mangled name for a function reference
> > would be useful. One common use case of that is dlopen, but this is
> > actually another. So instead of changing the ifunc attribute parser
> > accept expressions that can be folded to string constants and then the
> > mangled-name builtin.
> 
> As I understand it, with your suggestion, we'd then have something like:
> 
> ```c++
> template<typename T, int X>
> __attribute__(ifunc(__builtin_mangled_name(foo_resolver<T, X>)))
> foo() ...
> ```
> 
> When the compiler instantiates `foo`, it would try to generate the ifunc
> attribute.  This would trigger evaluation of the `__builtin_mangled_name`,
> which now evaluates to a constant because `T` and `X` are known, and after
> that all of the machinery works as normal?

Correct, that's the intention.

> I like this more than my suggestion for several reasons:
> 
>  - It decomposes into separately useful features
>  - It doesn't change anything about the ifunc attribute specifically and so
> if G++ wants specific template syntax there then we aren't committed to
> anything incompatible.
>  - It makes it easy for the ifunc resolver to ignore or transform some
> template arguments if they shouldn't affect codegen (for example, turning
> parameter `T` into `sizeof(T)` if codegen only cares about the size of the
> type and the type itself is used only for compile-time type checking.

Right, the one big semantic change for the attribute handling is that
changing from a string literal to some form of evaluated expression.
Otherwise, it composes well. Everything else I agree with.

> In terms of implementation, I see a couple of (not insurmountable)
> difficulties:
> 
> As I recall, the parser for attributes that take strings containing
> identifiers currently captures the string and resolves the identifier later.
> This would now have to capture an AST.
> 
> I think this is the only reason that attributes resolve differently for
> different template instantiations.  The template instantiation machinery
> would need to be told to do identifier resolution for all attributes during
> instantiation.

Also agreed on this.

Joerg