[LLVMdev] GSoC - Range Analysis

John Criswell criswell at illinois.edu
Mon Apr 2 18:27:18 PDT 2012


On 4/2/12 11:35 AM, John Regehr wrote:
>> from what I understand of the analysis, to come to its conclusions it assumes
>> that there is no overflow.  That doesn't make it useless for removing integer
>> overflow checks: you can successively walk variables, and if you can prove that
>> there is no overflow of a variable X given your analysis of previously seen
>> variables, then X can safely be added to the set of analysed variables.  Rinse
>> and repeat.  However this probably doesn't work for variables inside loops.
> I'd also be interested to hear more from the range analysis authors about
> this.
>
> Remaining faithful to the C/C++ overflow rules while operating on LLVM IR
> may be very tricky, particularly with respect to integer promotions and
> similar constructs, which may have no representation in the IR (even
> before optimization).
>
> An analysis that is not sound with respect to the original C/C++ semantics
> would be of little use to anyone.

I actually disagree on the last point.  For static array bounds checking 
with SAFECode, we want to assume that all integer operations can 
overflow (including those with the nsw attribute).  We don't care about 
the other integer semantic rules from C (like the promotion rules) or 
whether overflow is language defined or not (for those who don't know, 
unsigned ints have defined overflow in C; signed ints do not).  All we 
want to know is whether a pointer p is within the bounds of a set of 
valid objects, and we just need to take integer overflow into account 
because it can happen on the hardware.

-- John T.


>
> John
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list