llvm dev - Sep 2013 - [LLVMdev] Removing legacy profiling code from LLVM

Chandler Carruth wrote:
>Alright, I'm ready to nuke it. Last chance to say stop.
Stop.
>For context of others, this has come up repeatedly: no one we know of is
>using EdgeProfiling.cpp, PathProfiling.cpp, and the
>lib/Analysis/Profile*Pass.cpp collection of tools.
We've been actively using it since at least 2.8.  True, we haven't been
vocal about it.

While I can see perhaps getting rid of some of the older ProfileInfoT
related stuff, certainly the instrumentation portion and the metadata
loader (ProfileDataLoaderPass) portion are of use to us.

Isn't Bob Wilson also using, or at least interested in, some of the
metadata based profiling too?

While we're talking about it, there are associated portions under
runtime/libprofile that we're using too.
>...I would like to garbage collect and help pave the way for new stuff.
Have I missed a proposal somewhere?  I'd be interested to hear about what
you've got in mind.

  --Mike

On Sep 13, 2013, at 11:05 AM, msharp at codeaurora.org wrote:
> Chandler Carruth wrote:
> 
>> Alright, I'm ready to nuke it. Last chance to say stop.
> 
> Stop.
> 
>> For context of others, this has come up repeatedly: no one we know of
is
>> using EdgeProfiling.cpp, PathProfiling.cpp, and the
>> lib/Analysis/Profile*Pass.cpp collection of tools.
> We've been actively using it since at least 2.8.  True, we haven't
been
> vocal about it.
> 
> While I can see perhaps getting rid of some of the older ProfileInfoT
> related stuff, certainly the instrumentation portion and the metadata
> loader (ProfileDataLoaderPass) portion are of use to us.
> 
> Isn't Bob Wilson also using, or at least interested in, some of the
> metadata based profiling too?
No, I am not interested in any of the things that Chandler has proposed to
remove.
> 
> While we're talking about it, there are associated portions under
> runtime/libprofile that we're using too.
> 
>> ...I would like to garbage collect and help pave the way for new stuff.
> Have I missed a proposal somewhere?  I'd be interested to hear about
what
> you've got in mind.
Yes, there have been several different discussions based on proposal from me and
Diego.

On Fri, Sep 13, 2013 at 11:05 AM, <msharp at codeaurora.org> wrote:
> Chandler Carruth wrote:
>
> >Alright, I'm ready to nuke it. Last chance to say stop.
>
> Stop.
>
> >For context of others, this has come up repeatedly: no one we know of
is
> >using EdgeProfiling.cpp, PathProfiling.cpp, and the
> >lib/Analysis/Profile*Pass.cpp collection of tools.
> We've been actively using it since at least 2.8.  True, we haven't
been
> vocal about it.
>
> While I can see perhaps getting rid of some of the older ProfileInfoT
> related stuff, certainly the instrumentation portion and the metadata
> loader (ProfileDataLoaderPass) portion are of use to us.
>
> Isn't Bob Wilson also using, or at least interested in, some of the
> metadata based profiling too?
>
> While we're talking about it, there are associated portions under
> runtime/libprofile that we're using too.
>
Since I have seen no patches from you to this code since 2.8, maybe you
should move the pieces in the mainline tree to live with the pieces that
clearly are out-of-tree? I don't think we can support one half of a PGO
system in tree because the other half is in an out-of-tree repository. That
doesn't really make sense.

>
> >...I would like to garbage collect and help pave the way for new stuff.
> Have I missed a proposal somewhere?  I'd be interested to hear about
what
> you've got in mind.
>
>   --Mike
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130913/0c9e28ee/attachment.html>

It appears to me as if you're proposing removing all the existing
readers/writers, both the really old ones and the metadata ones, the
instrumentation passes, and the implied file format for profile data.  Is
this correct?

While I'm not against considering migrating our work, I think it would be
better if the new system was in place before removing the old.

  --Mike