[LLVMdev] ProfileInfo Questions -- How to proceed?
Andreas Neustifter
astifter-llvm at gmx.at
Thu Jan 21 02:20:51 PST 2010
Hi all,
I have some questions about the maintenance of the Profiling Code, since
this is largely my contribution I still feel responsible for it.
(I have not finished my master thesis, so it also is still work in
progress... :-)
When there are API changes in LLVM, I guess the person changing the API
is responsible for changing all the occurrences in LLVM? (So I do not
have to worry about that...)
The other thing is bugs and problems: I'm watching the llvm-bugs and
llvm-commits lists for profiling related posts, I hope that's enough to
keep everyone happy.
(I usually do not respond to build problems related to the runtime
library libprofile since I really can not help in that cases, I hope
this is okay too.)
Chris and me talked a while ago that he would like to see the
ProfileInfo implementation changed from an template-based one to a
(void*)-based one (for a lack of better terms).
I haven't wrapped my head around this, how important is this? Would it
be a showstopper for 2.7 if this stuff is still template-based?
And the (almost) last question:
How shall I proceed with preserving the ProfileInfo throughout the
various optimistation passes? I have a (huge) patch that adds support
for the std-compile-opts passes, but it is still not preserving all of
the ProfileInfo correctly. Is correctness a huge factor?
Or is having the preservation at least in a somewhat working state (so
that it is usable) more important?
In general terms it works fine, there are just some quirks where the
flow condition is not met. In my personal opinion the ProfileInfo is
still of some use after that...
And the last one:
When passes are added or modified and the ProfileInfo preservation
breaks, who is responsible for fixing it? I guess the ProfileInfo is the
only analysis that can not be recalculated after its destroyed (as
compared to e.g the LoopInfo) and thus has to be preserved (idealy)
everywhere, so this is quite an issue...
Sorry for the lengthy post, thanks for the answers in advance...
Andi
More information about the llvm-dev
mailing list