<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/11/2014 03:37 AM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KjYGQ2z6jNuaqh6=uS_nTnp+VHRCyA4nax5Muv=nqi+UQ@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</blockquote>
<blockquote
cite="mid:CAGCO0KjYGQ2z6jNuaqh6=uS_nTnp+VHRCyA4nax5Muv=nqi+UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
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. <br>
<br>
Philip<br>
</body>
</html>