<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 3:27 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 11 Feb 2014, at 01:25, Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br>

<br>
> 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.<br>

><br>
> 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.<br>

><br>
> 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.<br>

><br>
> 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"?<br>

<br>
</div>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.</blockquote>
</div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div>
</div>