<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/19/2018 11:57 AM, Friedman, Eli
via cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:861aa313-76d2-bf20-23b3-96e66b17ea6a@codeaurora.org">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">On 4/19/2018 11:48 AM, Manoj Gupta
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH=QcshhbvkNM-h2Cf_oYG=bo67RfiJzea-1eYAhBJadSEqo7Q@mail.gmail.com">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>