Analyzers
Talk to fellow users of Intel Analyzer tools (Intel VTune™ Profiler, Intel Advisor)

missing functions

cbabcock
Beginner
567 Views
I'm using VTune 7.1 and having a problem with the call graph.
Functions which do show up in the static module viewer don't show up as instrumented (marked as "Not defined as a Procedure in the Symbol Information"). One example is _ftol. It did show up earlier, but suddenly disappeared while I was trying to reduce the number of calls to it.
Other functions I'm trying to track in my code also tend to disappear or start returing self-times and total-times of 0 when I know they're expensive. They also lose their callees, even though I can see the calls in the assembly, and I know the function didn't get inlined.
I've checked that the project (VC 6.0) has the required settings (debug info,/fixed:no). I've also tried clearing the caches, removing the symbol repository modules, and recreating the activity.
Any other suggestions?

Message Edited by cbabcock@icarusstudios.com on 02-15-2005 03:15 AM

0 Kudos
5 Replies
David_A_Intel1
Employee
567 Views
So, you've figured out how to tell why the function is not instrumented (i.e., "Not defined as a Procedure in the Symbol Information"). The question then becomes why isn't the symbol defined as a procedure?
Something else that will keep the VTune analyzer from instrumenting a function is the first basic block being less than five bytes.
Since you are using Microsoft* Visual C++* 6.0, have you applied all service packs? If the symbol info is incorrect, there isn't anything that can be done in the analyzer to fix it. You might try a full rebuild ("Rebuild All")? Are you using "Edit and Compile" mode? Perhaps the build environment isn't rebuilding correctly afterwards?
0 Kudos
cbabcock
Beginner
567 Views
I'm not getting the less than 5 bytes comment on these functions (and the source doesn't show it to be too small, either).
I've got all the service packs installed for VC 6 (up to SP5) plus the processor pack for SP5. I've tried full rebuilds and various different project settings to see if I could get it working. The only way I could force it to work was disable all optimizes, but that doesn't make it very useful for testing optimizes :).
0 Kudos
David_A_Intel1
Employee
567 Views
Note: the "less than 5 bytes" is referring to the first basic block of the function and not the entire function.
When you say you disabled all the optimizations, are you using the Debug or Release build configuration? What if you start with the Debug build configuration, verify that you get all the functions you want and then start turning on optimizations for this configuration, verifying that the functions are still instrumented/present in call graph after each change/build?
Note: if optimizations are enabled and the compiler inlines a function, it will not show up in the graph.
Finally, you are using an older version of the analyzer. Version 7.2 was released late last year. You should try upgrading.

Message Edited by DaveA on 02-24-2005 11:18 AM

0 Kudos
cbabcock
Beginner
567 Views
It appears /Oy (frame-pointer omission) was causing it. I had already disabled inlining since I knew that would potentially remove the function; I had verified that wasn't the cause by checking to make sure the function had an actual call to it in the source view.
Did omitting the frame-pointer make the basic block too small? Removing the EBP register from use by the compiler for other optimizes doesn't seem like a good idea if I'm trying to profile the real code behavior.
0 Kudos
David_A_Intel1
Employee
567 Views
Good catch! And this is something that others can benefit from. I'm sure that omitting the frame pointer makes instrumentation impossible. Basically, call graph is replacing the code at the beginning of the function with a call to its collection code. When there is no frame pointer, it probably makes it impossible for call graph to do this.
I've never heard of this optimization before and I wonder how many others are using it?
If it is a requirement that you use this optimization, then you will need to stick with sampling to profile your code. Remember, call graph is ideally suited to algorithmic tuning, thus, it is not as critical that your app is built exactly as it will be released, as long as the calling sequence will not change. Also, call graph impacts the performance of the app by as much as 8X! So, use call graph to study the calling sequences and the algorithms and use sampling to profile execution of the application once the algorithm is nailed down.

Message Edited by DaveA on 02-28-2005 10:26 AM

0 Kudos
Reply