[LLVMdev] RFC - Extending ProfileInfo to support external profiles

Diego Novillo dnovillo at google.com
Fri Sep 6 11:18:43 PDT 2013

On Fri, Sep 6, 2013 at 1:01 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Fri, Sep 6, 2013 at 6:00 AM, Diego Novillo <dnovillo at google.com> wrote:
>> Is my understanding more or less correct?
> Probably for all I know. I'm not aware of anyone actively maintaining or
> keeping these pieces working. AFAICT, there have been 3-4 projects that
> started hacking on this and didn't finish, and frankly the result is a mess.
> It's not clear than any of it really works today.

OK. I was trying to use the instrumentation support and I could not
really get it to work. Clang does not understand the flags, and trying
to link the runtimes do not seem to get built by default (not a cmake
user, so I'm not sure how to build the library in runtime/libprofile).
 So, I gave up on figuring it out.

> I really think you should ignore the existing profile support in LLVM. ALl
> of it. I actually think we should remove all of it, but that can happen
> later.

OK.  Works for me.  I add a new pass in lib/Analysis then?

>> 2- Passes should not need to be aware that profile
>>    information exists. They would make the usual calls to the
>>    analysis API, which will use profile data, if available.
>>    With this, I want to make optimizers automatically make
>>    better decisions when profile information exists.
> I believe this has already been done. I'm not aware of any optimization
> passes in use today that will need changes here.

Odd, because in lib/Transforms I see several instances of:

  ProfileInfo *PI = getAnalysis*<ProfileInfo>();

followed by calls to fixup the profile information.  My thinking is
that we would hide all these inside the analysis API. Passes would ask
for, say, scalar evolution, which, in turn, will just use profile
data, if available.


More information about the llvm-dev mailing list