[LLVMdev] make DataLayout a mandatory part of Module

[Philip Reames]

On 02/11/2014 03:37 AM, Chandler Carruth wrote:
>
> On Tue, Feb 11, 2014 at 3:27 AM, David Chisnall 
> <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>
>     On 11 Feb 2014, at 01:25, Nick Lewycky <nlewycky at google.com
>     <mailto: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.
I agree that this is not the right place to continue this discussion.  I 
had intended to write up a proposal last week, but instead got 
distracted by actually writing code.  I should have separate proposal 
along these lines to the mailing list today.  I think we found a working 
middle ground in offline discussion, I'm hoping it won't be particularly 
controversial.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140214/50d5c338/attachment.html>