llvm dev - Dec 2014 - [LLVMdev] Incorrect loop optimization when building the Linux kernel

On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer
wrote:
> I'm pretty sure this is fixed in r223684.  This particular use of
> zero-sized arrays should defeat any chance of compile-time address
equality.
I object that change. It's a horrible special case hack for either a
fundamental issue in the IR or plain UB on the source level. As such, it
should be reverted.

Joerg

----- Original Message -----
> From: "Joerg Sonnenberger" <joerg at britannica.bec.de>
> To: "David Majnemer" <david.majnemer at gmail.com>
> Cc: "Chengyu Song" <csong84 at gatech.edu>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, December 8, 2014 2:22:47 PM
> Subject: Re: [LLVMdev] Incorrect loop optimization when building the Linux
kernel
> 
> On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer wrote:
> > I'm pretty sure this is fixed in r223684.  This particular use of
> > zero-sized arrays should defeat any chance of compile-time address
> > equality.
> 
> I object that change. It's a horrible special case hack for either a
> fundamental issue in the IR or plain UB on the source level.
I don't understand why you feel this way. It is a special case, yes, but
zero-sized types often induce special cases. The fact that we need to apply this
to opaque types is somewhat unfortunate, but regardless, the fact that a
zero-sized object can be assigned an address overlapping with another object
just seems like a fact of which the constant folder needs to be aware.

 -Hal
> As such,
> it
> should be reverted.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Mon, Dec 08, 2014 at 03:56:59PM -0600, Hal Finkel
wrote:
> ----- Original Message -----
> > From: "Joerg Sonnenberger" <joerg at
britannica.bec.de>
> > To: "David Majnemer" <david.majnemer at gmail.com>
> > Cc: "Chengyu Song" <csong84 at gatech.edu>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Monday, December 8, 2014 2:22:47 PM
> > Subject: Re: [LLVMdev] Incorrect loop optimization when building the
Linux kernel
> > 
> > On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer wrote:
> > > I'm pretty sure this is fixed in r223684.  This particular
use of
> > > zero-sized arrays should defeat any chance of compile-time
address
> > > equality.
> > 
> > I object that change. It's a horrible special case hack for either
a
> > fundamental issue in the IR or plain UB on the source level.
> 
> I don't understand why you feel this way. It is a special case, yes,
> but zero-sized types often induce special cases. The fact that we need
> to apply this to opaque types is somewhat unfortunate, but regardless,
> the fact that a zero-sized object can be assigned an address overlapping
> with another object just seems like a fact of which the constant folder
> needs to be aware.
There is a difference between zero-sized types and objects. For
zero-sized types, address operations are generally useless. There is no
object identity of any meaningful way. Zero-sized arrays share the same
property and that's why many languages declare them as invalid.

So back to the point -- either IR has to explicitly change to attach
semantics beyond C's "Don't do that" to zero-sized arrays and
other
object OR the commit is plainly wrong.

Joerg