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