[PATCH] D64412: [Strict FP] Allow more relaxed scheduling

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

I think I'll have to challenge you a little here. ;)

In D64412#1586343 <https://reviews.llvm.org/D64412#1586343>, @andrew.w.kaylor wrote:

> My understanding is that IEEE-754 requires us to produce an exception if and only if the exception would be produced by a literal interpretation of the source.


The literal interpretation language refers to value-changing optimizations. I don't think it specifies memory ordering though. I could be wrong...

> However, it does not require that the exceptions be raised in the same order as implied by the source. Also, that's what the LLVM language reference says we'll do with "fpexcept.strict" -- "The number and order of floating-point exceptions is NOT guaranteed." So, I think the changes you've got here are correct.

That's actually slightly different than what I'm asking -- that's about ordering two trapping operations (I'm not sure where that's specified as ok either), not ordering one trapping operation and a store.

In other words, what happens if we move stores around operations that can trap? I could easily write a small program to give different results based on whether this scheduling change is active or not. Is there somewhere that says different results are ok with same source?

I'm assuming we're treating it as undefined behavior, like the C/C++ Standards state, so that all this doesn't matter. Just want to confirm that we're not mistakenly throwing away strictness.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64412/new/

https://reviews.llvm.org/D64412