[llvm] r289147 - [SCCP] Make sure SCCP and ConstantFolding agree on undef >> a.

[Davide Italiano via llvm-commits]

On Sun, Dec 18, 2016 at 11:22 AM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> Why do we are about this?  What goes wrong if undef is folded to 0 in
> one way and -1 in the other?
>

I changed SCCP to integrate undef in the solver (see
https://github.com/llvm-mirror/llvm/compare/master...dcci:sccpng). In
particular, we don't ignore the return value of ConstantExpr::get() in
`visitBinaryOperator()`, so we get what ConstantFolding gives us. This
patch allows me to reduce the diff with what I have downstream, and I
also find it more consistent (unless there's a reason why the two
implementation should diverge). Does this make sense to you?

Thanks,

--
Davide

> On Thu, Dec 8, 2016 at 2:28 PM, Davide Italiano via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>> Author: davide
>> Date: Thu Dec  8 16:28:53 2016
>> New Revision: 289147
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=289147&view=rev
>> Log:
>> [SCCP] Make sure SCCP and ConstantFolding agree on undef >> a.
>>
>> Currently SCCP folds the value to -1, while ConstantProp folds to
>> 0. This changes SCCP to do what ConstantFolding does.
>>
>> Modified:
>>     llvm/trunk/lib/Transforms/Scalar/SCCP.cpp
>>     llvm/trunk/test/Transforms/SCCP/undef-resolve.ll
>>
>> Modified: llvm/trunk/lib/Transforms/Scalar/SCCP.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/SCCP.cpp?rev=289147&r1=289146&r2=289147&view=diff
>> ==============================================================================
>> --- llvm/trunk/lib/Transforms/Scalar/SCCP.cpp (original)
>> +++ llvm/trunk/lib/Transforms/Scalar/SCCP.cpp Thu Dec  8 16:28:53 2016
>> @@ -1396,8 +1396,8 @@ bool SCCPSolver::ResolvedUndefsIn(Functi
>>                break;
>>          }
>>
>> -        // undef >>a X -> all ones
>> -        markForcedConstant(&I, Constant::getAllOnesValue(ITy));
>> +        // undef >>a X -> 0
>> +        markForcedConstant(&I, Constant::getNullValue(ITy));
>>          return true;
>>        case Instruction::LShr:
>>        case Instruction::Shl:
>>
>> Modified: llvm/trunk/test/Transforms/SCCP/undef-resolve.ll
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/SCCP/undef-resolve.ll?rev=289147&r1=289146&r2=289147&view=diff
>> ==============================================================================
>> --- llvm/trunk/test/Transforms/SCCP/undef-resolve.ll (original)
>> +++ llvm/trunk/test/Transforms/SCCP/undef-resolve.ll Thu Dec  8 16:28:53 2016
>> @@ -135,7 +135,7 @@ define i32 @test6() {
>>    %t = ashr i32 undef, 31
>>    ret i32 %t
>>  ; CHECK-LABEL: @test6(
>> -; CHECK: ret i32 -1
>> +; CHECK: ret i32 0
>>  }
>>
>>  ; Make sure lshr produces a possible value
>> @@ -178,5 +178,5 @@ entry:
>>    %shr4 = ashr i32 undef, zext (i1 icmp eq (i32* bitcast (i32 (i1)* @test11 to i32*), i32* @GV) to i32)
>>    ret i32 %shr4
>>  ; CHECK-LABEL: @test11(
>> -; CHECK: ret i32 -1
>> +; CHECK: ret i32 0
>>  }
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
> --
> Sanjoy Das
> http://playingwithpointers.com



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare