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.
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.
>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.
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.
We chatted in person about getting the out-of-tree patches you have that are necessary to even remotely use the existing infrastructure posted, or otherwise show some progress on your end toward stepping up to maintain this code, and I waited a few weeks with no result.
At this point, I don’t think it is reasonable for the open source project to continue to carry this legacy, and I’m going to proceed with removing it. Naturally, you can resurrect all of this in your local tree since you have been maintaining one anyways, and given the total lack of updates this realistically shouldn’t cause you any extra work.
Hopefully, you’ll be able to help work with Bob and Diego (or others, or on your own) on ongoing work w.r.t. PGO in LLVM.