[PATCH] D55506: [RFC v2] Allow target to handle STRICT floating-point nodes

Mon Jun 3 13:17:51 PDT 2019

uweigand added a comment.

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

> Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

The BarrierChain tracks calls, volatile/atomic memory accesses, and UnmodeledSideEffects.  I do believe that FP exceptions must indeed be kept stable relative to those.

My patch does *not* entangle FP exceptions with regular memory accesses, which do *not* touch BarrierChain.

> Are there any cases where mayRaiseFPException should not imply hasUnmodeledSideEffects? If we checked mayRaiseFPException() inside the hasUnmodeledSideEffects() implementation a lot of these changes wouldn't be needed, and it might help with people who didn't think about FP exceptions in future changes.

Well, my last version did have FP exceptions implying UnmodeledSideEffects, and you didn't like that :-)   Specifically, that would mean that FP exceptions could not be moved across any normal memory access (since UnmodeledSideEffect instructions cannot) ...

> There is no way to distinguish between fpexcept.maytrap and fpexcept.strict after pattern matching. We could probably live with that, but it's less than ideal.

Well, to be honest I don't really see what the difference between those two at the MI level would be.  Can you explain e.g. how scheduling restrictions ought to differ?  If we have a need for that, we can just add a second MI flag.

> I'd like to see a solution that could handle rounding mode also. For rounding mode it will be even more important to have more than a single on/off flag. Do you have any ideas for that?

As I mentioned in the description, I believe rounding modes can be handled completely in the back-end, by simply modeling the FPC register (which I already committed on SystemZ).  Every FP instruction (strict or not) is modeled as a user of FPC, all assembler instruction that modify it (which are only a few special-purpose instruction) are modeled as a definition, and function calls within a FENV_ACCESS section should be marked by the front-end as having a variant ABI, which will cause the back-end to have them marked as clobbering FPC  (that last part is still missing, but is completely independent of everything that is done by this patch).  What aspect of rounding modes do you think is not covered by this approach?

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

https://reviews.llvm.org/D55506