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