[LLVMdev] Dependence Analysis [was: Flow-Sensitive AA]

Vikram S. Adve vadve at cs.uiuc.edu
Fri Aug 22 14:03:49 PDT 2008


Thanks!  This is all very interesting, and tells me that LLVM has a  
way to go to fully support all of these capabilities (if that is the  
right thing to do, which isn't clear).  OTOH, it looks like a lot of  
real-world software that is using LLVM already doesn't seem to be  
affected by the lack of them.

Does anyone know of any C/C++ programs that require integer overflow  
on signed arithmetic (even though it is not strictly allowed by the  
standard)?

Also, does anyone know how -ftrapv is implemented on processors that  
don't have hardware detection of integer overflow?  It sounds very  
expensive to do entirely in software.

Thanks,

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve




On Aug 22, 2008, at 3:50 PM, Mike Stump wrote:

> On Aug 22, 2008, at 9:34 AM, Chris Lattner wrote:
>> C has a way to express this: signed integers are defined to never
>> overflow, unsigned integers are defined to wrap gracefully on
>> overflow.
>
> And gcc has yet more fun in it:
>
>        -fstrict-overflow
>            Allow the compiler to assume strict signed overflow rules,
> depending on the language
>            being compiled.  For C (and C++) this means that overflow
> when doing arithmetic with
>            signed numbers is undefined, which means that the compiler
> may assume that it will
>            not happen.  This permits various optimizations.  For
> example, the compiler will
>            assume that an expression like "i + 10 > i" will always be
> true for signed "i".  This
>            assumption is only valid if signed overflow is undefined,
> as the expression is false
>            if "i + 10" overflows when using twos complement
> arithmetic.  When this option is in
>            effect any attempt to determine whether an operation on
> signed numbers will overflow
>            must be written carefully to not actually involve overflow.
>
>            See also the -fwrapv option.  Using -fwrapv means that
> signed overflow is fully
>            defined: it wraps.  When -fwrapv is used, there is no
> difference between
>            -fstrict-overflow and -fno-strict-overflow.  With -fwrapv
> certain types of overflow
>            are permitted.  For example, if the compiler gets an
> overflow when doing arithmetic
>            on constants, the overflowed value can still be used with -
> fwrapv, but not otherwise.
>
>            The -fstrict-overflow option is enabled at levels -O2, -
> O3, -Os.
>
>        -ftrapv
>            This option generates traps for signed overflow on
> addition, subtraction,
>            multiplication operations.
>
>        -fwrapv
>            This option instructs the compiler to assume that signed
> arithmetic overflow of
>            addition, subtraction and multiplication wraps around
> using twos-complement
>            representation.  This flag enables some optimizations and
> disables others.  This
>            option is enabled by default for the Java front-end, as
> required by the Java language
>            specification.
> _______________________________________________
> 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