<div dir="ltr"><div>Nicolai,</div><div><br></div><div>  I don't think that's the correct  change either but I wanted to get a quick summary of potential failures. You're right it's not entirely dependent on 'contract' or 'reassoc' when the global flag is set, ie -fp-contract=fast, as in your X86 example, this is essentially setting 'contract' on every instruction.</div><div><br></div><div> I think it would be add a 'nocontract' fast math flag. The issue is that when -fp-contract=fast is set and there isn't a 'contract' or 'reassoc' on an instruction, how do you not contract it and still contract other instructions that also don't have the 'contract' or 'reassoc' set when -fp-contract is present.</div><div><br></div><div>-Ryan</div><div><br></div><div>  </div><div><br></div><div><br></div><div><br></div><div>  </div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 23, 2018 at 10:47 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22.08.2018 23:53, Ryan Taylor wrote:<br>
> Just a quick change of isContractableFMUL to isContractable gives about <br>
> 49 unexpected failures.<br>
<br>
That may not be the right change to be looking at. Consider:<br>
<br>
>      LLVM :: CodeGen/X86/fma_patterns.ll<br>
<br>
This file doesn't use any `contract` or `reassoc` flags on IR instructions.<br>
<br>
I don't know what's changed there, but the point is that the test does <br>
not depend on the exact semantics of `contract` and `reassoc`.<br>
<br>
Cheers,<br>
Nicolai<br>
<br>
-- <br>
Lerne, wie die Welt wirklich ist,<br>
Aber vergiss niemals, wie sie sein sollte.<br>
</blockquote></div>