<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 01/04/2016 09:55 AM, Amaury SECHET
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANGV3T2CLd_cocdkhw5DgUPpO1qXuVc1teAqy66sPdzMvNXe7Q@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">2016-01-04 18:21 GMT+01:00 Philip
            Reames <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF"><span class="">
                  <div>On 01/04/2016 07:32 AM, Amaury SECHET wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div>
                        <div>After a bit more investigation, it turns
                          out that because %0 is stored into %1 (after
                          bitcast) and so %3 may have access to it and
                          clobber it.<br>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> Can you give a bit more context?  I'm not sure
                which of the examples you're talking about.<br>
                <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Sure. Let's look at <a moz-do-not-send="true"
                href="http://pastebin.com/K0J9yGq1">http://pastebin.com/K0J9yGq1</a><br>
              <br>
            </div>
            <div>Because of the store line 7, it is assumed that the
              call line 8 may see %0 and even modify the memory it
              points to. As a result, it is assumed that the load line
              11 may not be eliminated.<br>
              <br>
            </div>
            <div>Which seems actually correct in the general case.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    This seems like a restatement of what I said in my original
    response:<br>
    "You have to teach the alias analysis that an unescaped noalias
    pointer can't alias the global state allocmemory might access. 
    Slightly surprised we don't get this today, but oh well. "<br>
    <br>
    Or am I missing something?<br>
    <blockquote
cite="mid:CANGV3T2CLd_cocdkhw5DgUPpO1qXuVc1teAqy66sPdzMvNXe7Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><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 text="#000000" bgcolor="#FFFFFF"><span class=""><br>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div>
                        <div><br>
                        </div>
                        After a bit of thought, it is correct in the
                        general case, but definitively something
                        stricter is needed here. Looking at <tt><span>inaccessiblememonly</span></tt>
                        I'm not sure this is what is needed. What if the
                        memory allocator is defined is the current
                        module ?<br>
                      </div>
                    </div>
                  </blockquote>
                </span> At the moment, inaccessiblememonly would require
                separate compilation of the allocation function.  <br>
                <span class="">
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div><br>
                      </div>
                      This leads me to conclude this is way more linked
                      to the memory allocation pass than I expected it
                      to be in the first place. Can I ask what you plan
                      to use <tt><span>inaccessiblememonly</span></tt>
                      for ? Should the semantic be refined to fit the
                      bill better ?<br>
                    </div>
                  </blockquote>
                </span> Well, I didn't introduce the attribute, so I
                can't speak for the original intent.  For me, I plan on
                applying it to some of our out of line allocation
                functions and other helper routines which modify runtime
                state, but not java visible state.  <br>
                <br>
                If you have specific suggestions for how to refine the
                semantics, please make them.  Getting the details right
                is always the hard part.  :)<br>
                <br>
                You might also consider using a variant of your
                allocation function which takes a pointer to the global
                state it needs to modify.  Doing this would allow you to
                use argmemonly to restrict the aliasing while still
                allowing whole program optimization.  I haven't tried
                this in practice, but it seems like it would probably
                work...<span class=""><br>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>I do not wish to make suggestion before I understand
              where this is coming from. So far, from what I've
              collected, use cases are:<br>
            </div>
            <div> - Memory allocation<br>
            </div>
            <div> - Runtime isolation for managed languages.<br>
            </div>
            <div><br>
            </div>
            <div>I have some more though to put into this, but to boot,
              would that be possible to only use this attribute on
              method that are declared, but not defined and remove it
              when merging modules ? </div>
          </div>
        </div>
      </div>
    </blockquote>
    This seems semi reasonable.  I haven't thought through the
    implications, but it might be worth considering.  <br>
    <br>
    <blockquote
cite="mid:CANGV3T2CLd_cocdkhw5DgUPpO1qXuVc1teAqy66sPdzMvNXe7Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>It doesn't look like it is necessary to have it when
              the function may be exposed depending on the way the
              software is built.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Er, not sure what you meant here.  <br>
    <br>
    Philip<br>
    <br>
  </body>
</html>