[PATCH] D30661: [x86] Split MXCSR into two pseudo-registers

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

In https://reviews.llvm.org/D30661#693773, @efriedma wrote:

> > A subsequent patch will update floating point operations to add an implicit use of the control bits and an implicit def of the status bits
>
> This seems kind of confusing... strict floating-point ops need to implicitly use and def the status bits, because the new value depends on the previous value. You can think of an FP operation as a logical OR acting on the status register.  Many kinds of code motion are legal (e.g. you can reorder FP operations with each other, or hoist them out of loops).  But if you omit the use, other optimizations won't work correctly; for example, dead code elimination will eliminate FP operations which have a visible effect on the status register.
>
> Given that, I'm not sure what splitting the status register buys you; I guess it becomes easier to check whether an instruction modifies the control bits?


My goal was to restrict the motion of FP operations relative to the instructions that set the control bits or read the status bits without imposing unnecessary restrictions.  I believe we agreed when this was discussed previously that the order of exceptions does not need to be preserved, so long as all exceptions are accounted for in the status bits.

I am indeed introducing this register modeling with a view to supporting strict floating point semantics.  Initially I intended to model MXCSR use as you indicated, with all strict FP operations having an implicit use and def of this register.  However, I was having problems finding a clean way to communicate the fact that an operation required strict semantics across the ISel boundary.  This split register modeling was an attempt to get something that was "strict enough" for the strict case without imposing a restriction on the default case.

I suppose you are correct that this has a vulnerability to operations being DCE'd.  I'm not sure preserving  exception status from floating point operations whose results are never used is a critical use case.  I guess that depends on the way we document the semantics of strict FP support.  I'll have to think about that.

There is also a question to be resolved as to which function calls should act as barriers and which should not, or in the present context I suppose that equates to which should clobber MXCSR and which should not..


Repository:
  rL LLVM

https://reviews.llvm.org/D30661