How to uniquely remember a loop?

Hi-

I am writing a pass to traverse loops and collect some analysis data and later on come back to transform the IR. In the analysis phase I need to remember statistics regarding every loop in the program. What is the best way to uniquely remember a loop?

Thanks,

-Prashantha

Probably too late to help you but... loops are identified by their header block. Depending on your situation you might directly point to the block or refer to its name. If you need to be more robust across CFG optimization and inlining, you'll have to use debug info instead.
-Andy

More than one loop may share the same header; I can certainly run LoopSimplify as a prepass. But will that ensure unique loop header for each loop. As I will be performing transformation after the analysis other optimizations will not interfere (hopefully).

Will the debug info metadata be available always? If so, what are good pointers to explore?

Thanks,
-Prashantha

More than one loop may share the same header;

You have a different definition of loop than the rest of the optimizer. You can identify your loops by the backedge if you prefer.

I can certainly run LoopSimplify as a prepass. But will that ensure unique loop header for each loop.

It tries to split loops into single back edge loops. No guarantee.

As I will be performing transformation after the analysis other optimizations will not interfere (hopefully).

Now it sounds like you're writing a standard in-process Analysis pass that can be used by your transformation without being invalidated. If so, just refer directly to Loop* from LoopInfo.

Will the debug info metadata be available always? If so, what are good pointers to explore?

Certainly no guarantee. Do you want your optimization to depend on debug info?

-Andy

More than one loop may share the same header;

You have a different definition of loop than the rest of the optimizer. You can identify your loops by the backedge if you prefer.

I can certainly run LoopSimplify as a prepass. But will that ensure unique loop header for each loop.

It tries to split loops into single back edge loops. No guarantee.

As I will be performing transformation after the analysis other optimizations will not interfere (hopefully).

Now it sounds like you're writing a standard in-process Analysis pass that can be used by your transformation without being invalidated. If so, just refer directly to Loop* from LoopInfo.

Will the debug info metadata be available always? If so, what are good pointers to explore?

Certainly no guarantee. Do you want your optimization to depend on debug info?

-Andy

Andy-

I will go with an Analysis phase followed by transformation phase and I will make LoopInfo run as prepass for analysis. That should make LoopInfo valid when I run analysis and transform.

Thanks,
-Prashantha

Hi there,

I guess I did something like this some time ago: I needed a set of infos about some loops, but the code should be modified only in another moment. In that case, I just created two dynamic passes for opt: an analysis and a transformation pass, and both of them were LoopPasses. After that, I simply accessed the data from my analysis directly from my transformation, and the machinery in LLVM itself took care of the sync between them (linking a transform to the analysis of each respective loop, and keeping the results of the analysis alive, even if some other transformation caused my analysis to be invalidated).

In order to access the analysis, you might need check the getAnalysisUsage method: http://llvm.org/docs/WritingAnLLVMPass.html#getAnalysisUsage
You might remember that the header file of your analysis must be accessible from your transformation code location (I kept all the files in the same directory).

The only catch in here is that you need to include all the code of the analysis in its header file. I don’t know exactly why, but when I tried to create a separate .cpp file, I couldn’t link the code.

And, last, you might invoke your passes just importing all dynamic libraries you created (in my case, I just linked both passes into one dynamic library), and you might use only the flag for your transformation (the LLVM should call your analysis automatically), except in case you have more than one implementation of your analysis – so, you should explicitly invoke the one you want, if it is not the default one.

Hope I could help,