[LLVMdev] Incorrect loop optimization when building the Linux kernel

[Joerg Sonnenberger]

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