[LLVMdev] make DataLayout a mandatory part of Module

[Chandler Carruth]

On Tue, Feb 11, 2014 at 3:27 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 11 Feb 2014, at 01:25, Nick Lewycky <nlewycky at google.com> wrote:
>
> > Your IR won't do any shifty pointer-int conversion shenanigans, and you
> want some assurance that an optimization won't introduce them, or that if
> one does then you can call it out as a bug and get it fixed. I think that's
> reasonable, but I also think it's something we need to put forth before
> llvm-dev.
> >
> > Note that pointer-to-int conversions aren't necessarily just the
> ptrtoint/inttoptr instructions (and constant expressions), there's also
> casting between { i64 }* and { i8* }* and such. Are there legitimate
> reasons an optz'n would introduce a cast? I think that anywhere in the
> mid-optimizer, conflating integers and pointers is only going to be bad for
> both the integer optimizations and the pointer optimizations.
> >
> > It may make sense as part of lowering -- suppose we find two alloca's,
> one i64 and one i8* and find that their lifetimes are distinct, and i64 and
> i8* are the same size, so we merge them. Because of how this would
> interfere, I don't think this belongs anywhere in the mid-optimizer, it
> would have to happen late, after lowering. That suggests that there's a
> point in the pass pipeline where the IR is "canonical enough" that this
> will actually work.
> >
> > Is that reasonable? Can we actually guarantee that, that any pass which
> would break this goes after a common gc-root insertion spot? Do we need
> (want?) to push back and say "no, sorry, make GC roots better instead"?
>
> I am not currently working on GC, but I am working on a back end for an
> architecture in which pointer integrity is enforced in hardware and
> pointers and integers have different representations and different
> representations and so I would also find much of this contract for
> optimisations useful.  Round tripping via an int involves data loss on my
> architecture and having optimisations insert these can be annoying (and
> break security properties).  I imagine that the situation is similar for
> most software-enforced memory safety tools, not just GC.


While I find all of these things very interesting from the perspective of
security and/or hardware constraints, I don't think we should try to deal
with that here.

Today, even without a datalayout, I suspect LLVM is not providing nearly
the guarantee that either of these use cases is looking for. It may well
work by happenstance, but hope isn't a strategy. If we want to add this
constraint to LLVM, let's discuss that separately. I don't think we have it
today, and I don't think making datalayout mandatory meaningfully moves us
further from having it. At worst it causes already possible random failures
to become more common.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140211/23ff1288/attachment.html>