[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