[cfe-dev] Using IFUNC with template functions

[David Chisnall via cfe-dev]

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?

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.

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.

If these problems can be addressed, this sounds like a great feature.

It might be possible to simplify the implementation by capturing the 
string "__builtin_mangled_name(foo_resolver<T, X>)" in the attribute and 
then re-parsing the string at template instantiation point but this may 
introduce more complications that I haven't thought of.

David