<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/26/2016 10:10 AM, Chandler
Carruth via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KgRz3RDzAznLh2K7yTo75Wtq4pJLZC0hDB3dpgQX2adGw@mail.gmail.com"
type="cite">
<div dir="ltr">To what Reid said, I'm not really worried about
impact on the middle end of any of this. We can handle the code
changes, etc.
<div><br>
</div>
<div>I agree with Chris about what we're trading off here:<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 25, 2016 at 10:48 PM Chris
Lattner via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="gmail_msg">I’d argue the other side of it.
The quality of the code is higher if we have
invariants (like all globals are pointers) because
that simplifies assumptions by eliminating cases where
“is a pointer” appears to be true, but isn’t actually
true in all cases. I’m not an expert on CFI or how
widely it will ultimately impact the compiler hacker
consciousness, but I’m pretty sure that the current
model for globals and functions will remain more
prominent. If you choose to break this invariant,
you’ll be continually swimming upstream against
assumptions made throughout the compiler, both in code
written today but also in code written in the future.<br
class="gmail_msg">
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I agree that mental assumptions the developers on the
middle end hold are the primary challenge here. But I
think we are going to run into challenges either way.</div>
<div><br>
</div>
<div>If the type of these entities is an integer, we will
have a non-pointer global, yes. But as Peter points out,
this is caught effectively by asserts in the cast
infrastructure and other programming aids. Essentially,
the checking of LLVM's type system helps protect the
random middle end developer from getting this wrong.</div>
<div><br>
</div>
<div>On the other hand, if the type of these entities
remains consistently pointers, we will still break
assumptions that middle end developers routinely make
about pointers to globals:</div>
<div>- They aren't dereferencable</div>
<div>- They aren't aligned</div>
<div>- They may be null</div>
<div>- The difference between them might not be
representable in a pointer-sized-integer</div>
<div><br>
</div>
<div>In essence, their *values* won't behave like pointers
even if we make the LLVM IR type a pointer. So the wrong
assumption will shift from an IR type system error to a
value error. I would generally much prefer the LLVM IR's
type system catch this kind of error. Even if these wrong
assumptions about the values are much less common, I would
prefer the more common but easily caught type system
error.</div>
<div><br>
</div>
<div><br>
</div>
<div>To Rafael's point, while I agree that at the object
file level these are indeed addresses, I personally am
much more interested in the IR modeling things in ways
convenient to the middle end optimizer than to the linker.
And there, the above seems like the dominant tradeoff.</div>
<div><br>
</div>
<div><br>
</div>
<div>Anyways, if Reid, Chris, and Rafael all strongly feel
like keeping the types consistent is actually the right
tradeoff, I don't want to stand in the way. So far, I just
find the arguments for why this is the right tradeoff
unconvincing.</div>
</div>
</div>
</div>
</blockquote>
I agree with Chandler here on pretty much all of this (including the
willingness to be ignored if consensus goes the other way.)<br>
<blockquote
cite="mid:CAGCO0KgRz3RDzAznLh2K7yTo75Wtq4pJLZC0hDB3dpgQX2adGw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>-Chandler</div>
<div><br>
</div>
<div><br>
</div>
<div>PS: In case it isn't clear, I'm totally fine with
having the range metadata available for the case where
globals are mapped into very specific regions for bare
metal / embedded architectures, but *should* be treated as
actual addresses of objects that can be loaded and stored
through. And those seem unambiguously like they should be
pointers. But that seems like a separate use case and
discussion...</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>