[llvm-commits] [llvm] r122801 - /llvm/trunk/lib/Transforms/Scalar/CodeGenPrepare.cpp

[Cameron Zwarich]

On Jan 3, 2011, at 10:10 PM, Jakob Stoklund Olesen wrote:

>>> Is the fix-point loop in CodeGenPrepare still necessary? When critical edge splitting is disabled?
>> 
>> I've just been running some experiments on this. The fixed point loop is probably necessary for the 'ext' optimizations, as a lot of 'ext' casts get optimized after other instructions have been sunk into their block. On all of test-suite + SPEC2000 & SPEC2006, there are only 4 noop copies optimized in a later iteration (these don't really matter as they will be eliminated by the coalescer later), but there are 15 memory instructions that have their addressing code sunk into their BB in a later iteration. I was thinking of just iterating the ext optimizations afterwards, possibly based on a worklist, but it would be nice to know why these memory instructions have sinkable addressing code after the first iteration.
> 
> It is probably chained bitcast / ext / gep instructions getting lowered one at a time.
> 
> If that is the case, you could probably get away with iterating over each basic block separately instead of re-checking the whole function. That assumes that the chains to be lowered already were in the same basic block. I have no idea if that is generally true.
> 
> It would be safer and faster to add the operands of lowered instructions to a work list, but that is a bit more work to implement.

I tried implementing this, only reiterating over each basic block after optimizing a memory instruction instead of rechecking the whole function. I got the following results on test-suite + SPEC2000 & SPEC2006. This seems to disagree with my previous printf-based approach to counting the extra improvements.

Before:

153583 Number of GEPs converted to casts
14501 Number of [s|z]ext instructions combined with loads
85788 Number of blocks eliminated
210298 Number of memory instructions whose address computations were sunk
150811 Number of uses of Cast expressions replaced with uses of sunken Casts
28255 Number of uses of Cmp expressions replaced with uses of sunken Cmps
17221 Number of uses of [s|z]ext instructions optimized

After:

153583 Number of GEPs converted to casts
14459 Number of [s|z]ext instructions combined with loads
85788 Number of blocks eliminated
208697 Number of memory instructions whose address computations were sunk
150126 Number of uses of Cast expressions replaced with uses of sunken Casts
28230 Number of uses of Cmp expressions replaced with uses of sunken Cmps
17263 Number of uses of [s|z]ext instructions optimized

I guess I'll still have to work at getting it closer in code quality. Maybe I'll need to make all of the optimizations feed into a worklist, which could be tricky. Currently, it's about a 10% improvement in total llc time, though.

Cameron