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