RFC: Change of strict FP operation representation in IR

[spavloff]

@nikic

@spavloff

Descriptive names help new developers understand the code but increase verbosity, while shorter names enhance readability. Choosing between long and short names for rounding modes will likely influence other control modes as well. For example, compare these:

call float @llvm.nearbyint.f32(float %x) [ "fp.control"(metadata !"rte", metadata !"daz", metadata !"ftz") ]

and

call float @llvm.nearbyint.f32(float %x) [ "fp.control"(metadata !"round_to_even", metadata !"denormal_as_zero"), metadata !"flush_to_zero" ]

We just need to choose the more convenient naming.

For what it’s worth, I prefer the second variant in terms of verbosity (without commenting on the specific strings used here).

Especially as there already is a lot of syntactic overhead anyway, I don’t think saving a handful of characters here at the expense of clarity is worthwhile.

No problem. We can use the same encoding as we do now for constrained intrinsics, it is familiar to developers. Taking into account the note below about splitting “fp.control” and making similar changes in denorm bundles, the syntax could be:

call float @llvm.nearbyint.f32(float %x) [ "fp.round"(metadata !"tonearest"), "fp.denorm.in"(metadata !"preserve-sign"), "fp.denorm.out"(metadata !"positive_zero"), "fp.except"(metadata !"ignore") ]

@nikic

@spavloff

All FP computational operations have side effects, there is no way to turn them off. Thus, the basic form of an FP instruction is the form with the side effects. Only if the function code obeys to certain restrictions, these side effects may be ignored, and the FP operations can behave as pure functions. This means that the side effects of FP operations are determined solely by strictfp function attribute. Operand bundles, as well as metadata arguments of constrained intrinsics, cannot alter it. Even if a constrained function call has an argument fpexcept.ignore, it still has side effects.

I don’t really agree with this view, at least in terms of how we want to model these operations in LLVM IR. Note that there are multiple effects involved here. For most FP operations, the most general set of effects will be something like memory(fp_rounding_mode: read, fp_denormal_mode: read, ..., fp_status: write).

Let’s just look at fp_rounding_mode: read to start. @fadd() ["fp.control"(metadata !"round_to_nearest")] does not have a fp_rounding_mode: read effect, because the (effective) rounding mode is fixed. Importantly, this is true regardless of whether the operation is inside a strictfp function or not.

It depends on how we want to model these operations in LLVM IR. if @fadd() ["fp.round"(metadata !"round_to_nearest")] does not have a side effect, it means that rounding mode in this case is considered as static. This representation is slightly more abstract than the existing constrained intrinsics. But it has advantages including:

• more possibilities for optimizations,
• natural implementation of pragma STDC FENV_ROUND,
• possibility to use static rounding in default mode.

It however requires a dedicated pass that would insert necessary set_/get_rounding calls to preserve the semantics on targets without static rounding.

Using static rounding for specific (non-dynamic) modes seems like a good approach. It allows us to use static rounding freely in LLVM IR for any target, but eventually we should replace static rounding with dynamic before the instruction selection.

@nikic

For fp_status: write the situation is more along the lines of what you said, in that the operation always (potentially) writes the FP status, but fpexcept.ignore allows us to ignore this effect. But regardless of what the underlying hardware behavior is, the way we’d be modelling this at the IR level is still fp_status: none.

The key point is that exceptions cannot be ignored in strictfp environment, and fpexcept.ignore cannot change that. For example:

inline float divide(float x, float y) {
  // default fp mode.
  return x / y;
}

float calculate() {
  #pragma STDC FENV_ACCESS ON
  …
  y = sin(x);
  exc = fetestexcept(MASK))
  …
  c = divide(a, b);
  …
}

In this case, the divide function produces a division instruction with fpexcept.ignore flag, since it originates from a default-mode function. If this instruction had fp_status: none attribute, nothing would prevent the compiler from placing the instruction between the instruction that use exceptions:

  y = sin(x);
  c = divide(a, b);
  exc = fetestexcept(MASK))

In a strictfp function, an IR instruction fadd with fp_status: none cannot be realized with just a single target fadd instruction - it requires at least a pair of fegetenv and fesetenv. This makes the use of fp_status: none in strictfp functions a source of misunderstanding. Most transformation based on this property in LLVM seem to be incorrect. The only valid use is eliminating instructions with unused results, even if the instruction may raise exceptions. For example, the following call may be removed by compiler, although it raises an exception:

    %unused = call double @llvm.experimental.constrained.fdiv.f64(double 0.0, double 0.0, metadata !"round.upward", metadata !"fpexcept.ignore" 

Some users think this behavior is incorrect. If they are right, fp_status: none in strictfp function is useless, instructions with and without this attribute behave identically. Consequently the entire parameter “fpexcept” can be removed, as the exception handling would be determined only by the function attribute ‘strictfp’.

If we choose to maintain per-instruction exception handling flags, we must define its semantics more precisely and establish a set of potential use cases for this flags. I would drop it completely, - exception handling is defined by the entire code, it is not a choice of an individual function. It however could be made later, no need to tie this decision with this proposal.

@nikic

Regarding the discussion on static rounding modes, I generally agree with what you’re saying, but the part I’m still missing is how the current functionality of constrained FP intrinsics can be represented under the new model.

The current implementation supports only two models: default mode and strictfp mode with dynamic rounding. It is possible to create an IR with instructions that use specific rounding modes, but clang does not produce such code and it is unlikely that some MLIR or other LLVM-based code generator creates strictfp code that uses non-dynamic rounding.

So the current functionality of constrained FP intrinsics consists of only dynamic rounding. All constrained intrinsics have side effect to prevent undesirable reorder and this is vital for strictfp implementation. All these properties are preserved in the proposed implementation.

@nikic

As I understand it, your proposal allows specifying either a dynamic rounding mode or a static rounding mode, but it has no way to encode an assumed rounding mode.

I would propose to consider difference between static and assumed modes as a low-level implementation detail and leave the choice between them to the compiler. fadd executes identically (produces the same results) no matter if rounding mode is specified in the instruction or is read from a register.

If a case arises where it is really necessary to distinguish between them, rounding mode bundle could be amended with an appropriate flag, for example:

call float @llvm.nearbyint.f32(float %x) [ "fp.round"(metadata !"tonearest,dynamic" ]

@nikic

If you specify a static rounding mode and the target does not allow per-instruction rounding modes, then LLVM will be forced to change the dynamic rounding mode around the instruction to lower it, which would be very inefficient – especially if there is prior knowledge that the dynamic rounding mode is already set to the correct value.

Yes, you are right. Support of static rounding mode requires some IR transformation that would insert set_rounding and get_rounding to emulate semantics of static rounding. However it is required anyway if we want to implement pragma FENV_ROUND, this is not a drawback of this proposal. The C standard explicitly points out that static rounding may be implemented in this way: https://www.iso-9899.info/n3047.html#7.6.2p5. And yes, a target with hardware support of static rounding would have benefits.

@nikic

Is this just not a use-case anyone cares about? Otherwise we should have a replacement for it. (A possible replacement would be to make the strictfp attribute more fine grained, so we can express things like “the rounding mode inside this functions is known to be xyz”. If function-granularity is sufficient for this.)

Most of the information needed for the transformation, that converts static rounding to dynamic, can be obtained from analyzing the function code. If pragma FENV_ROUND is used without FENV_ACCESS, we know that no user function modifies rounding mode, and we can insert functions that change rounding mode optimally. Otherwise the user intends to mix static and dynamic modes and the things are more complicated. Compiler intrinsics and standard C functions have known behavior and the pass can use this information. The main challenge lies with user functions, they can change rounding mode and should be treated as barriers making rounding mode unknown. It this is not sufficient, a special function attribute indicating that the function changes rounding mode, can be introduced.