[llvm-commits] [PATCH] Don't PRE compares

Jakob Stoklund Olesen jolesen at apple.com
Thu Mar 8 15:35:29 PST 2012


On Mar 8, 2012, at 2:54 PM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Mar 8, 2012, at 10:53 AM, Jakob Stoklund Olesen wrote:
> 
>> The attached patch stops GVN from eliminating partially redundant compare instructions.
>> 
>> CodeGenPrepare sinks compares to their uses so that they can be fused with branches in isel. The phi node inserted by PRE prevents the sinking, and increases register pressure by forcing the i1 value into a general purpose register.
>> 
>> There is no way for CodeGenPrepare to figure this out on its own. Run the included test case through opt -O2 to see how value propagation messes with the i1 phi:
>> 
>> %cmp3.pre-phi = phi i1 [ %cmp1, %if.then ], [ false, %entry ]
>> 
>> Owen suggested a more radical approach: Don't PRE instructions that have a single use in the same block. It solves a more general version of the same problem: PRE separates instructions that the code generator might have been able to fuse.
> 
> Makes sense to me.  Are there any cases where PRE'ing the compare could cause it to constant fold to true or false in all predecessors?  If so, then we'd like to keep PRE'ing in that case to enable jump threading.

I don't think so, but it depends on the pass ordering.

GVN's PRE will never duplicate an instruction, it will only move it if it is missing in exactly one predecessor, and available in all other predecessors. Wouldn't the compares in the other predecessors already have been constant folded if they could?

PRE only creates a new opportunity for constant folding in the predecessor the gets the new instruction.

In the present test case, the compare is constant folded by value propagation which runs after jump threading.

/jakob




More information about the llvm-commits mailing list