[LLVMdev] SCEV expression for ICmpInst

Jud Leonard jud.leonard at gmail.com
Sat Apr 17 11:35:37 PDT 2010


Be careful about oversimplifying signed integer comparisons -- integer arithmetic can easily overflow, so you cannot transform A > B to A - B > 0.  The compare instructions in most processors do not simply subtract and test the most significant bit; they compute what the sign of the difference would be in extended precision.

On Apr 17, 2010, at 1:00 PM, llvmdev-request at cs.uiuc.edu wrote:

> Message: 13
> Date: Sat, 17 Apr 2010 22:17:54 +0800
> From: ether zhhb <etherzhhb at gmail.com>
> Subject: [LLVMdev] SCEV expression for ICmpInst
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID:
> 	<s2w5f72161f1004170717re1325ffdr53b6b7308215b3fa at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> i am playing the ScalarEvolution these days. i found the the ScalarEvolution
> will simply return a SCEVUnknow for a ICmpInst, so i think maybe great to
> add a new kind of SCEV to the ScalarEvolution framework.
> 
> 
> for example, if i run  ScalarEvolution on the bc file generate from the
> following C source file:
> 
> int f(int a, int b, int c, int d) {
>    return (2 * a + 5 * c + 2) > (4 * d - 3*b +3);
> }
> 
> i will get a SCEVUnknow for the compare instruction, but it's great if i
> could get something like 2 * a + 5 * c - 4 * d - 3*b - 1 > 0 for the compare
> instruction :)
> 
> 
> In my opinion, we need only 3 kind of SCEV expression to express the
> ICmpInst: SCEVEqCond for equal condition,  SCEVNeCond for not equal
> condition and SCEVGtCond for others. Because we can always transform A < B
> to B > A, and transform A >= B to A > B - 1 (or A + 1> B), and A <= B to A <
> B + 1 (or A - 1 < B). Furthermore, we can transform A > B to A - B > 0 and A
> != B to A - B != 0, so the SCEV for conditions will be very simple.
> 
> As there are already some functions such as "isKnownNonZero" in
> ScalarEvolution, so we can compute these condition easily.
> 
> With the SCEV for conditions, we may write more meaningful code:
> 
> SCEVEQCond *S = SE.getCondition(some_icmp_instruction);
> 
> if (some_cond.isAlwaysTrue(SE))
>  ... do some thing ...
> else
>  ... do some others thing ...
> 
> Dose this make sense? or i just make things unnecessarily complex?
> 
> any comment is appreciated.
> 
> --best regards
> ether





More information about the llvm-dev mailing list