[llvm] r184222 - During SelectionDAG building explicitly set a node to constant zero when the

[Quentin Colombet]

On Jun 20, 2013, at 5:14 AM, Duncan Sands <duncan.sands at gmail.com> wrote:

> Hi Quentin,
> 
> On 18/06/13 22:14, Quentin Colombet wrote:
>> Author: qcolombet
>> Date: Tue Jun 18 15:14:39 2013
>> New Revision: 184222
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=184222&view=rev
>> Log:
>> During SelectionDAG building explicitly set a node to constant zero when the
>> value is zero.
> 
> you could also set it explicitly to -1 when all bits are sign bits.
Yes, you are right.
> 
>> This allows optmizations to kick in more easily.
>> Fix some test cases so that they remain meaningful (i.e., not completely dead
>> coded) when optimizations apply.
>> 
>> <rdar://problem/14096009> superfluous multiply by high part of zero-extended
>> value.
> 
> ...
> 
>> Modified: llvm/trunk/test/CodeGen/ARM/mvn.ll
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/mvn.ll?rev=184222&r1=184221&r2=184222&view=diff
>> ==============================================================================
>> --- llvm/trunk/test/CodeGen/ARM/mvn.ll (original)
>> +++ llvm/trunk/test/CodeGen/ARM/mvn.ll Tue Jun 18 15:14:39 2013
>> @@ -1,4 +1,4 @@
>> -; RUN: llc < %s -march=arm | grep mvn | count 8
>> +; RUN: llc < %s -march=arm | grep mvn | count 9
> 
> Is this an improvement?
Yes, but it is not obvious from the way the check is written though.
Indeed, the sequence:
mov	r0, #0
sub	r0, r0, #3
becomes
mvn	r0, #2

> 
> ...
>> Modified: llvm/trunk/test/CodeGen/X86/2007-10-12-CoalesceExtSubReg.ll
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/2007-10-12-CoalesceExtSubReg.ll?rev=184222&r1=184221&r2=184222&view=diff
>> ==============================================================================
>> --- llvm/trunk/test/CodeGen/X86/2007-10-12-CoalesceExtSubReg.ll (original)
>> +++ llvm/trunk/test/CodeGen/X86/2007-10-12-CoalesceExtSubReg.ll Tue Jun 18 15:14:39 2013
>> @@ -7,8 +7,10 @@ entry:
>>  cond_next127:		; preds = %cond_next391, %entry
>>  	%v.1 = phi i32 [ undef, %entry ], [ %tmp411, %cond_next391 ]		; <i32> [#uses=1]
>>  	%tmp149 = mul i32 0, %v.1		; <i32> [#uses=0]
>> -	%tmp254 = and i32 0, 15		; <i32> [#uses=1]
>> -	%tmp256 = and i32 0, 15		; <i32> [#uses=2]
>> +	%tmpss = load i32* %ss, align 4		; <i32> [#uses=1]
>> +	%tmpbp = load i32* %bp, align 4		; <i32> [#uses=2]
>> +	%tmp254 = and i32 %tmpss, 15		; <i32> [#uses=1]
>> +	%tmp256 = and i32 %tmpbp, 15		; <i32> [#uses=2]
> 
> This looks like a regression.
No, it is not, I have to modify the input of test to prevent dead code eliminate to remove everything.
Thus, this is a complexification (is that a word?) of the test to exerce something... I have to admit what I was about to remove this test has the code was completely dead before the change in the input.

-Quentin

> 
> Ciao, Duncan.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130620/cca476bd/attachment.html>