erichkeane wrote:

> @AaronBallman Hi, I will quickly cover my motivation for this.
> 
> Basically, I want to implement a "function wrapper", in which we can insert 
> code snippets before and after the function, e.g., performance instruments. 
> Like the following:
> 
> ```c++
> <typename T>
> struct FunctionWrapper;
> 
> <typename R, typename ...Args>
> struct FunctionWrapper<R(Args...)> {
>    R (*inner)(Args...);
>    R operator()(Args... &&args) {
>        // before snippets
>        R ret = inner(std::forward<Args>(args)...);
>        // after snippets
>        return ret;
>    }
> };
> ```
> 
> Most of the time, it works. Until I face a function pointer with _calling 
> convention_, e.g., `__fastcall___`. In this case, we cannot assign inner = 
> _fastcall function pointer_.
> 
> So in this case, one way I think of is:
> 
> ```
> wrapper = +[] static (auto... args) [[gnu::copy(inner)]] { inner(args...); }
> ```
> 
> so that I can use a lambda instead to implement the wrapper and preserve the 
> calling convention. It works on GCC, but I found that Clang does not support 
> copy attribute.

I'd be more open to something more specific here.  We made it ~7 years without 
implementing this/anyone really caring/complaining/etc, so I don't see reason 
to pick up everything this way.

I MIGHT be open to something that did calling-convention-only and was explicit 
about it.  But the problem I have in particular is how this: 

1-picks up expressions instead of simple names.  This makes the functionality 
ambiguous/gets tie breaker rules that are fairly opaque and easy to run afoul 
of.
2- Lies.  It copies SOME of the attributes, and a fairly awkward collection of 
them.
3- Becomes really awkward/weird with attributes who change meaning based on 
point-of-use, particularly around point-of-instantiation.
4- Doesn't seem to properly handle ambiguous names in any real way.  C in 
particular has the ability to have multiple names available based on kind/name 
space, and the name ends up not being clear.  AND If I read this right, decays 
to 'expression' use instead.

SO I think this attribute is particularly problematic for these and many other 
reasons.  IF all you wish to copy is calling convention, I'd be open to some 
sort of well-architected/designed attribute/set of attributes to do the 
well-motivated things.

https://github.com/llvm/llvm-project/pull/229355
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to