[LLVMdev] Indirect call site profiling

[betulb at codeaurora.org]

> On 10/24/14, 8:26 PM, betulb at codeaurora.org wrote:
>> Hi All,
>>
>> We've been working on enhancing LLVM's instrumentation based profiling
>> by
>> adding indirect call target profiling support. Our goal is to add
>> instrumentation around indirect call sites, so that we may track the
>> frequently taken target addresses and their call frequencies.
>>
>> The acquired data has uses in optimization of indirect function call
>> heavy applications. Our initial findings show that using the profile
>> data
>> in optimizations would help improve the performance of some of the spec
>> benchmarks notably.
>
> Can you quantify "notably?" Also, do you profile on one set of inputs
> and then test the optimization on another set of inputs (e.g., the test
> and train runs)?

I can't give numbers, but we do collect data from train runs.

>>   We have a proof of concept implementation,  which we
>> plan to put it up for review. However, I’d like to inquire prior if
>> there
>> are any plans or ongoing work done in the community to enable indirect
>> call target profiling support or not. Please inform if cfe-dev is a
>> better
>> candidate for posting PGO related emails.
>
> Interesting. I did not think SPEC had many programs with a lot of
> indirect function calls.

Spec does have programs such as gcc, vortex and others which use indirect
calls. I'm planning to have an RFC soon on the feature. I'll follow it w/
the patch for the profiler changes for clang, llvm and compiler-rt.

> It would be interesting to see what your optimization would do on an
> operating system kernel like FreeBSD or Linux. The VFS (file system)
> layer uses function pointers a lot, but I'm not sure if it's the
> dominant overhead.
>
> Have you tried on C++ programs? They should be making heavy use of
> indirect function calls as well.
>
> If you make your software public, please let me know. Adapting your work
> for kernel execution and trying it out on a kernel might be a nice
> project for one of our students.
>
> Regards,
>
> John Criswell
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochester
> http://www.cs.rochester.edu/u/criswell
>
>