[cfe-dev] [cfe-commits] r154321 - in /cfe/trunk: include/clang/Driver/CC1Options.td include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.h lib/CodeGen/CGObjCGNU.cpp lib/Driver/Tools.cpp lib/Frontend/CompilerInvocation.cpp test/CodeGenObjC/trace.m

[David Chisnall]

On 9 Apr 2012, at 19:03, Douglas Gregor wrote:

> New features should meet the criteria outlined in http://clang.llvm.org/get_involved.html#criteria . It is not at all obvious how this extension meets those criteria.

As I understand it, and understood it when they were being drafted, those are the criteria for a new language feature.  This is not a new language feature.  It has no impact on parsing or semantic analysis.  It merely provides some profiling hooks, which were requested by the community, designed based on feedback from the community, and implemented in the LLVM coding style.

> Technically, why isn't Pajé simply interposing an instrumentation library to gather this information, either at link time or at run time? That would be less invasive for both users and for Clang developers, and far more likely to work correctly in general. 

Not true.  With the traditional GNU method two-stage dispatch mechanism it is not possible to interpose anything between message sends at the library level (the runtime simply returns a method pointer, so you can't run code after the message send, only at some arbitrary time before it).  Even with a NeXT-style dispatch mechanism it is difficult to get enter and exit events, because the objc_msgSend() functions tail-call the real implementation.  

This would also make it very difficult to selectively trace part of the program.  This can easily be done with the current implementation, it would be impossible with a library-based implementation (we had a prototype that worked that way, and it had numerous limitations even when integrated into the runtime).

> At the larger level, why should we be adding a separate code-generation mode for one visualization library for one runtime?

The patch adds hooks that any consumer can use.  Pajé is the first to use them, but they can also be used by any other consumer of this information, including gprof-style tools. 

> It's not even the dominant runtime by far, so we're serving a very tiny user base with this new feature.

We're also not affecting any users of Apple runtimes, or, indeed, anyone who doesn't explicitly turn it on.  This was presented in the GAP presentation at FOSDEM this year and there was a lot of interest from Objective-C developers in seeing it working.  

Taking that argument to its logical conclusion, we're only serving a tiny userbase by supporting the GCC and GNUstep Objective-C runtimes at all, or by supporting, for example, platforms like NetBSD.  

David