llvm dev - Aug 2008 - [LLVMdev] Dependence Analysis [was: Flow-Sensitive AA]

On Friday 22 August 2008 16:14, Daniel Berlin wrote:
> On Fri, Aug 22, 2008 at 5:03 PM, Vikram S. Adve <vadve at
cs.uiuc.edu> wrote:
> > 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)?
>
> Yes, see the unending discussion on the gcc mailing list about
> programs we are breaking that led to the introduction of this option.
>
> My serious suggestion would be to tell any users who require this flag
> to shove it.
>
> :)
Right on!
> (Otherwise you end up in a very dark place because there are a lot of
> optimizations that make assumptions about overflow when rearranging
> expressions, etc).
Exactly right.  One of my first jobs here was to fix a bunch of overflow 
problems exposed by optimization.  It's now become a tradition to
give this task to any new optimizer employee.  :)

                                                  -Dave

On Aug 22, 2008, at 4:27 PM, David Greene wrote:
> Exactly right.  One of my first jobs here was to fix a bunch of  
> overflow
> problems exposed by optimization.  It's now become a tradition to
> give this task to any new optimizer employee.  :)

But that sounds like Cray is being fairly conservative in treating  
overflow problems as errors during optimization.  Is that correct?   
That's more or less the opposite of what Dan Berlin was suggesting.

This is not just idle curiosity -- I'm trying to get an understanding  
of what real-world compilers are actually doing on this issue.

--Vikram

On Friday 22 August 2008 17:07, Vikram S. Adve wrote:
> On Aug 22, 2008, at 4:27 PM, David Greene wrote:
> > Exactly right.  One of my first jobs here was to fix a bunch of
> > overflow
> > problems exposed by optimization.  It's now become a tradition to
> > give this task to any new optimizer employee.  :)
>
> But that sounds like Cray is being fairly conservative in treating
> overflow problems as errors during optimization.  Is that correct?
> That's more or less the opposite of what Dan Berlin was suggesting.
All the problems I fixed involved Cray being too aggressive.  We needed to
add checks to handle unsigned int overflow.  Customer codes were breaking.
For unsigned int in C compilers *must* be conservative because that's what
the standard says.  This pops up in places you might not expect, right now
deep into the guts of expression reordering and canonicalization.  Because
of this, various higher-level optimizations that depend on expressions being
in a certain form also tend to get shut down because the canonicalizer can't
reorder them.

Unsigned arithmetic is just evil.
> This is not just idle curiosity -- I'm trying to get an understanding
> of what real-world compilers are actually doing on this issue.
Absolutely.  Lots of nasty stuff starts to happend with unsigned arithmetic.
As I understand it, -fwrapv is for those codes that violate the standard -- 
they assume signed arithmetic wraps.  I've not seen any real-world codes
that depend on that but the gcc guys certainly see a lot more C than we do.

                                                 -Dave