I've been using Intel's VTune Analyzer v8.0 for Windows to profile my application that is compiled from within MSVS2003 with Intel's C++ Compiler v9.0. When building in either "Debug" or "Release" mode, I can identify the hotspots that are generating the most samples. However, I can only view the full source of the application when the sampling is done for the "Debug" executable. If "Release" was active, only a portion of the source is available; when I try to view the most important function (60-70% of the program execution time) I get the error:
"The function you selected is in the range of current source file, but it doesn't have source. Try switching to one of the Mixed modes or to Disassembly only mode in order to see the disassembly of this function."
I've verified that the compiler debug information format is "Program database /Zi" (have even tried /ZI), the linker has "Yes (/DEBUG)" selected for generator debug information, and "/fixed:no" is passed to the command line. Why would I be able to see the source for some functions but not others? Other information which may be helpful is that I'm using /O3 or /Ox for optimization and making use of processor specific instructions (e.g. SSE3).
This is probably due to aggressive compiler optimizations.The compiler can do all sorts of things, such as inlining, moving code around to optimize for locality, etc. It's not a debug info issue.
When you aggressively optimize with the compiler, you probably need to view the performance data at a higher level, such as the Hotspot view, since the mapping of source to instructions becomes very difficult.
If you doubt that, try using /FAcs to generate commented assembly listing. Try it both with and without /Qinline_debug_info.
In interesting (optimized) cases, you'll get very different results for the association between asm and source line. But either way you'll get mostly reasonable results, that are correct within their own strange rules.
Either the compiler is failing to put as good information into debug info as it has for building /FAcs files, or (I think more likely) Vtune is failing to understand that information.
I have worked mainly with an older compiler and older Vtune, and only today got Vtune 8.0. (I had the compiler 9.0 but couldn't get older Vtune to work with it at all).
With older versions, I found one set of severe Vtune problems (related to the topic here) when not using /Qinline_debug_info and a very different set of such problems when not using /Qinline_debug_info. Most often not using it gave better Vtune results (but that varied with which section of my application I was investigating).
I happened to have /Qinline_debug_info turned on for the last build before I got Vtune 8.0. So those are the only Vtune 8.0 results I have so far. I'm seeing all of the advantages from /Qinline_debug_info that I found in previous versions, and I'm seeing only some of the problems. So it might be that trying /Qinline_debug_info is enough of an answer for pdonahue. (But I would like a better answer myself).
Displaying data for inlined functions is problematic and something the VTune analyzer team has been grappling with. At this point in time, there are cases where the display of the sampling data for an inlined instance of a function is not optimal. The best thing to do, if you know it is an inlined function, is to switch to the assembly view and look at the actual instructions. This will always be correct.
Debug info for inlined functions is evolving and future releases of the VTune analyzer may present the data more effectively.
However, I don't believe this is related to the problem that pdonahue is seeing.
Message Edited by DaveA on 04-11-2006 10:57 AM