<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 3:21 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    On 09/10/2014 02:42 PM, Kevin Modzelewski wrote:<br>
    <blockquote type="cite">
      <div dir="ltr">We have some similar cases and wanted the same
        thing; what we were doing for a while is using the third "is
        constant" field of the TBAA metadata and setting that to 1.  I'm
        not 100% sure what the semantics of that are -- LangRef says it
        means that pointsToConstantMemory() returns true which means
        that the memory is "impossible ... to be modified", which seems
        like not quite a fit for this set-exactly-once use case.  In
        practice, looking at the IR after our optimization pipeline, we
        were getting the results we wanted: if a store and subsequent
        loads were seen together, the store would remain and the value
        would be forwarded to all the loads.  (I don't think I looked at
        the "multiple loads with no visible store which should get
        collapsed to a single load" case.)  ymmv</div>
    </blockquote></span>
    I hadn't looked at this approach much, but based on the
    documentation, you're basically just asking for miscompiles here. 
    The semantics seem to be the same as "invariant.load".   While the
    optimizer happens to not be removing the stores, it seems like it
    would be perfectly legal for it to do so.  </div></blockquote><div><br></div><div>Yeah, agreed that it's risky based on the documentation, but it feels like this is the intended use case for that "is constant" TBAA field, since I'm not sure when the described semantics could be useful.</div></div></div></div>