[cfe-dev] How to go about generating wrapper functions when a particular attribute is seen?

[Seth Goldstein via cfe-dev]

The basic goal is the support low-cost parallelism when necessary.
The wrapper function provides some glue which allows the original
function to be invoked as a micro-thread.

So, either the original function or the wrapper function will be
called, depending on certain conditions.  There are no "ignorant"
translation units.  (In fact, as an extra, I would like the attribute
to be attached to both definitions and declarations so I can check the
use proper use of these functions.)



--------------
Seth Copen Goldstein
Carnegie Mellon University
Computer Science Dept
7111 GHC
412-268-3828

On Wed, Nov 15, 2017 at 11:14 PM, John McCall <rjmccall at apple.com> wrote:

>
> On Nov 15, 2017, at 10:32 PM, Seth Goldstein via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> I am wondering what the best approach would be to generate a wrapper
> function for functions with a particular attribute.  I.e.,
>
> When the compiler sees
>
> __attribute__ ((wrapthis)) int foo(args) {}
>
> I want to generate foo as usual and also generate a function
>
> int
> foo_wrapper(args)
> {
> // do some stuff here
> int result = foo(args);
> // do some more stuff here
> return result;
> }
>
> I am not sure where to generate the wrapper function, e.g., in clang,
> in llvm?  And, what pass could I look at that might provide me with
> some hints about how to go about this.  Any help would be appreciated.
>
>
> A feature like this could be implemented in many different ways, so it's
> hard to answer
> your question without more basic information.  How are you anticipating
> this wrapper
> function being used?  Are all existing uses of the function re-routed to
> it?  Is it important
> that "ignorant" translation units use the wrapper function?  Is it
> important that ignorant
> translation units *not* use the wrapper function?  What's the basic goal
> here?
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171116/050f13ed/attachment.html>