[llvm-commits] [patch] Implement a pass to instrument function entry and exit

Chris Lattner clattner at apple.com
Sun Jun 13 22:50:38 PDT 2010


On Jun 13, 2010, at 3:30 PM, Nelson Elhage wrote:

>> 
>> However, backing up a little bit, I'm not sure I understand this from the GCC man page:
>> 
>> "This instrumentation is also done for functions expanded inline in other functions."
>> 
>> Does that mean that *all* source-level function (that don't have the
>> no_instrument_function attribute) get instrumented, even if they get
>> inlined etc?
> 
> That's correct.
> 
> (As of GCC 4, there is a complication, which is that as of GCC 4,
> inlined functions call __cyg_profile_* with the address and caller of
> the function _they were inlined into_, instead of passing the address of
> the non-inlined version of the function. (See
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23296). I'm not sure whether
> we want to duplicate the GCC behavior, which I and at least two others
> find confusing (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28205), or
> do something else. But in any case, yes, all source-level functions get
> instrumented).

Yeah, that sounds like a bug.

>> If so, then I think this entire thing can be handled in the Clang IR
>> generation routines, not needing LLVM IR attributes and not needing an
>> LLVM IR pass.
>> 
>> What do you think?
> 
> What do you see as the advantage to handling this from clang, instead of
> as an LLVM IR pass? My intuition would be that making this an IR pass is
> desirable because you might want to instrument code generated by
> something other than clang, but I don't yet have a strong feel for the
> overall architecture and where the clang/LLVM split is.

My main aim is to reduce complexity in LLVM IR.  Adding another attribute just for this would introduce complexity that doesn't seem essential to the task of describing the program.  Because of that, if possible, I'd prefer to handle this in clang directly.

Thanks again for working on this!

-Chris



More information about the llvm-commits mailing list