[LLVMdev] [polly] pass ordering

[Tobias Grosser]

On 04/17/2013 08:13 PM, Hal Finkel wrote:
> ----- Original Message -----
>>
>> If you can find a pass ordering that does not regress too much on the
>> performance and scop coverage of the current one, but that has Polly
>> integrated in the normal pass chain just before the loop passes, that
>> would be a great improvement.
>
> I thought that, when we discussed this in November, the goal was to have Polly scheduled to run just prior to the loop vectorizer, etc. That way we could split the analysis off and it could be (optionally) reused by the vectorization passes without being invalidated by other transforms.

This is another good point. We want to run the loop vectorizer as close 
as possible after Polly.

This is the current list of passes.

MPM.add(createLoopRotatePass());            // Rotate Loop
MPM.add(createLICMPass());                  // Hoist loop invariants
MPM.add(createLoopUnswitchPass(SizeLevel || OptLevel < 3));
MPM.add(createInstructionCombiningPass());
MPM.add(createIndVarSimplifyPass());        // Canonicalize indvars
MPM.add(createLoopIdiomPass());             // Recognize idioms like
                                                memset.
MPM.add(createLoopDeletionPass());          // Delete dead loops

if (LoopVectorize && OptLevel > 2)
   MPM.add(createLoopVectorizePass());

As I said, I would like to run Polly before the LICM pass and possibly 
also before the loop rotate pass. The question is if any of those loop
passes between Polly and the loop vectorizer would be problematic or 
possibly even beneficial. I believe that after Polly there will be 
opportunities for LICM, loop rotation, instruction combination, and 
possibly loop idiom recognition. I believe doing this after Polly and 
before vectorization is a good thing. The loop.parallel markers are 
hopefully robust enough to survive up to the loop vectorizer. If one 
pass really does invalidate them, we can probably teach the pass to keep 
them.

Cheers,
Tobias