<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 3:02 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 Jan 2015, at 10:51, David Majnemer <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>> wrote:<br>
><br>
> I don't think this should be a flag on add.  Flags are designed such that the middle-end may be ignorant of them and nothing bad might happen, it is always safe to ignore or drop flags when doing so is convenient (for a concrete example, take a look at reassociate).<br>
<br>
</span>This is true of metadata, not of flags.  Consider the atomic memory order on loads and stores, for example.  It is definitely not safe for an optimiser to ignore these.<br></blockquote><div><br></div><div>The arithmetic operations are *very* consistent that flags imply a relaxation of constraint: floating point has fast math flags, division has exact, etc.</div><div>Memory instructions seem to have gone in the other direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div></div>