[LLVMdev] Obtaining and using block frequencies in MachineScheduler.cpp

Matthias Hartmann Mat321 at web.de
Wed Mar 13 05:43:12 PDT 2013


Dear Dev-Team,

I am currently in the process of writing my bachelor thesis. The topic is about the implementation and evaluation of trace scheduling in the llvm framework for VLIW architecture. Simplifying the problem, only loop free code will be processed. Further, preparations and studies of llvm framework have shown, that, in my humble opinion, the machineScheduler::runOnMachineFunction() would be the best place to start with. Later the code will be put into a separate class like the HexagonMachineScheduler and the MachineScheduler will be reverted back to it's original state. This is an outline of my concept on how to implement this basic trace scheduling approach.

Progressing in this plan, I encountered different problems. The first one is about the compiler infrastructure with its passes. I already figured out, that compiling the llvm-bitcode into target-assembler is done in different steps, e.g. analysis, etc. Are there any further documents available helping me to understand this infrastructure?

The next and most confusing problem is about gaining profile data on the program I want to compile. Especially the block frequencies are of high importance for me to find the most common trace through the CFG. Therefore, I searched for some guides, but I could not find an appropriate one. Most of them are referring to "opt" and "llvm-ld". Reading the change log of llvm3.2, the llvm-ld tool is not deprecated but replaced by other tools. Until now I was not able to figure out how to use them in a correct way, to add the profile data for an existing .bc file. Further I am uncertain about how do I add an existing pass and get the information?
I already tried to answer the question by myself by reading several guides and documentations about using the getAnalysis and getAnalysisUsage functions where passes can be required. 

Thanks in advance for your efforts and your help.


Kind regards,

Matthias Hartmann



More information about the llvm-dev mailing list