<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, 2018 at 11:59 AM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org">efriedma@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-5412967785433185009moz-cite-prefix">On 4/19/2018 11:57 AM, Friedman, Eli
via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div class="m_-5412967785433185009moz-cite-prefix">On 4/19/2018 11:48 AM, Manoj Gupta
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr" style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">On
Wed, Apr 18, 2018 at 12:54 PM Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>>
wrote:<br>
</div>
<div dir="ltr" style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br>
</div>
<div dir="ltr" style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br>
</div>
<blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">On
Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>>
wrote:</span> </blockquote>
<blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Despite the name,
the flag actually has rather straightforward semantics<br>
> from the compiler's perspective. From the gcc docs for<br>
> -fdelete-null-pointer-checks: "Assume that programs
cannot safely<br>
> dereference null pointers, and that no code or data
element resides at<br>
> address zero." (-fno-delete-null-pointer-checks is the
opposite.)<br>
<br>
Ah, now that's quite a bit more palatable. I really should
have read<br>
the docs before spouting "my favourite rant #1". Then my
main concern<br>
is that we end up with a sufficiently clear (and documented)<br>
definition that we're not promising more than we intend. I
get very<br>
grumpy if I can't tell someone with UB that they're Doing It
Wrong.<br>
<br>
Of the two options, I still think the second is a
non-starter.<br>
Something between the two might be a datalayout flag
specifying<br>
addrspace(0) behaviour. It's pretty easy to argue that it'd
be good if<br>
code used some kind of<br>
"DataLayout::isPointerIntrinsicallyInvalid(Value *)" for
this kind of<br>
thing anyway (rename or relocate at will).<br>
<br>
And the name really is terrible, we should change it if at
all feasible</blockquote>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Apr 18, 2018 at 1:46 PM Jon
Chesterfield via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>I'm working with an embedded architecture that
could, in some situations, run faster if code or data
could be located at address zero. I don't know whether
this applies to other embedded chips.</div>
<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Despite the
name, the flag actually has rather straightforward
semantics <br>
from the compiler's perspective. From the gcc
docs for <br>
-fdelete-null-pointer-checks: "Assume that
programs cannot safely <br>
dereference null pointers, and that no code or
data element resides at <br>
address zero." (-fno-delete-null-pointer-checks
is the opposite.)<br>
<br>
-Eli<br>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div> Thanks Tim and Eli,</div>
<div>I should have put the GCC description for the flag in
the email.</div>
<div><br>
</div>
<div>Regarding the suggestion to DataLayout, It is an
interesting idea. I like it in particular since it will
avoid creating a new llvm optimization flag and is auto
embedded in IR.</div>
<div><br>
</div>
<div>Given that, how do we want to proceed, do we want to
add yet another field to the DataLayout string?</div>
</div>
</div>
</blockquote>
<br>
Modifying the datalayout is not a good idea; it doesn't interact
with LTO correctly, and the frontend and the backend generally
need to agree on the datalayout.<br>
<br>
You could maybe use a module flag, if the address-space thing
doesn't work for some reason, but we don't like to introduce more
of those if we can avoid it.</blockquote>
<br>
Actually, thinking about it a bit more, a function attribute would
be better than a module flag. But I'd still like to explore the
address-space thing first, since we already have the LLVM
infrastructure to make that work.<br>
<br>
-Eli</div></blockquote><div><br></div><div>Thanks Eli,</div><div><br></div><div>I was looking around for the cases where AddrSpace !=0 are checked. Seems like there are a bunch of optimizations that will fail to apply for non zero address spaces.</div><div>So I'll start with the function attribute approach.</div><div><br></div><div>-Manoj</div><div><br></div><div><br></div></div></div>