First, thanks Mehdi for putting something on llvm-dev and getting wider awareness of this.
I am actually really interested in finding a way for LLVM to support the interesting functionality we are missing from fenv-like interfaces. Things like rounding modes, exceptions, etc. However, I think the current design is going to be a really high burden for the entire optimizer and I think there is a simpler model that we might pursue instead.
I’ll start off with some underlying principles that I’m operating from:
a) Most code in the world will be very happy with the default floating point environment, doesn’t need to carefully model floating point exceptions, etc. Essentially, I think that LLVM’s behavior today is probably right for most code. Now, the code which needs support for the other features of floating point isn’t bad or unimportant! But it is relatively speaking rare, and so I think it is reasonable to optimize the representation model for the common case provided we don’t lose support for functionality.
a) When outside the default floating point environment’s rules, there are few if any optimizations that we realistically expect from LLVM. Certainly, any changes to the LLVM optimizer which impact code outside the default needs to be done much more carefully to avoid introducing subtle bugs.
OK, based on that, consider the following model:
We provide intrinsics that mirror the instructions ‘fadd’, ‘fsub’, ‘fmul’, ‘fdiv’, and ‘frem’ (so 5 total). From here on out, I’ll exclusively use ‘fadd’ as my examples. The intrinsics would look like:
declare {f32, i1} @llvm.fadd.with.environment.f32(f32 %lhs, f32 %rhs, i8 %rounding_mode, i8 %exception_behavior)
Then we define specific values to be used for the IEEE rounding modes. And we define values to control exception behavior. I’m not an expert on floating point exceptions in particular (my platforms don’t use them) but I’m imagining three states “ignore”, “return”, and “trap”. I’ve used a single ‘i1’, but I’m assuming it would need to be several i1s or an iN in order to model the set of FP exceptions. I’m using i1 here just to simplify the explanation, I think it generalizes and I’ll let the experts suggest the exact formulation.
If the default rounding mode is provided to these intrinsics and the “ignore” exception behavior is provided, they behave exactly as the existing instructions do, and instcombine should canonicalize to the existing instructions.
The semantics of non-default rounding modes are to perform the operation with that rounding mode.
If “return” is provided for the exception behavior, then the i1 component of the result is true if an FP exception occured and false otherwise. If “ignore” is provided then any FP exceptions are ignored and the i1 is always false. If “trap” is provided then the i1 is always false, but the call to the intrinsic might trap. We could either define a trap as precisely the same as a call to @llvm.trap(), or we could introduce an @llvm.fp.trap() and define it as a call to that.
The frontend would then be responsible for lowering floating point arithmetic using these intrinsics. This may be somewhat challenging because in the frontend behavior is controlled dynamically in some languages. In those situations, we can either allow these intrinsics to accept non-constant arguments for %rounding_mode and %exception_behavior so that frontends can emit code that just dynamically computes them, or we could follow the same model that atomics use, and if the frontend cannot trivially compute a constant, it can emit a switch over the possible states with a specific intrinsic call in each case. I don’t have strong opinions about which would be best, I think either could be made to work.
If we go with constant arguments being required, we could use “metadata arguments” which aren’t actually metadata but just encoded arguments for intrinsics.
When emitting constants and trying to respect floating point environment settings, frontends will have to emit runtime calls instead of actual constants. But this seems actually good because that is what we’ll need anyways – we aren’t able to with full generality emulate all the environment options if I understand things correctly (and let me know if I’ve misunderstood).
The two really big reasons why I like this model much more than extending flags are:
-
This avoids implicit state. The implicit state of the floating point environment makes things like code motion extremely hard to reason about. I think we will just get it wrong too often to make this a good approach. By modeling all of this as actual SSA values I think there is a much better chance we’ll get this stuff right. For example by or-ing all the i1s for floating point exceptions and testing the result to implement fetestexcept. Then the backend can spill the state when necessary and reload it when needed even if other floating point math is introduced. I admit that first class aggregate returns aren’t a beautiful way to encapsulate this, but they are an effective way that we know how to work with in the LLVM IR. If we ever come up with a better multi-def model, we can always switch these and all the other intrinsics which need this to that model.
-
Every pass will conservatively correctly model the operations. This is most significant when modeling trapping on exceptions. We need every pass to realize that control flow might not proceed past such operations. We already have this logic for calls, and it seems a really nice fit for allowing most of the optimizer to be unaware of these constructs while respecting them and preserving behavior in the face of them.
I suspect that there are things this model doesn’t handle that I’ve not thought of (as this is outside the are of FP that I’m deeply familiar with), but I really think this model would be easier to reason about and would be much less invasive within the IR and optimizer. I wonder if folks think this could work and would be up for moving their efforts in this direction?
-Chandler
