clarification needed for the constrained fp implementation.

Hi Brian,

I was just cleaning up my inbox and saw that I had never responded to your e-mail below. I apologize for that. It was not intentional. Did the subsequent discussion answer your questions?

In any event, let me address your specific question about the language reference, where it says “These intrinsics are used to provide special handling of floating point operations when specific rounding mode or floating point exception behavior is required” (your emphasis repeated for discussion). The idea here was that these intrinsics can be used to control the behavior of the optimizer, in order to allow non-default rounding mode and floating point exception behavior. The “required” behavior must be expressed in the IR, as always, but the intrinsics only perform the operation they are documented to perform. I suppose I should clean up the language reference to make this less ambiguous.

It’s unclear to me whether your processor supports directly encoding the rounding mode into floating point instructions. If it does not, then I don’t see how having the semantics of the intrinsics force a given rounding mode would help, as the generated code would still require instructions that explicitly set the rounding mode before (and possibly after) each floating point instruction. If your processor does allow the rounding mode to be encoded in an instruction, then I can understand the desire to have a way to encode that into the IR, but for the IR to remain target-independent we would still need to support targets that do not have this capability. My earlier suggestion of intrinsics to establish a “local” rounding mode was intended to enable this sort of model.

Regarding your question about having to save and restore the rounding mode when calling a function, I think that depends on the language-specific semantics of the function you are calling. The C99 standard, for instance, requires that functions not change the rounding mode unless they are specifically documented as doing so and that any function called is assumed to require the default rounding mode unless it is specifically documented otherwise. (The FENV_ACCESS pragma can provide a sort of “documentation” for locally defined functions in this regard.) So, basically, it’s up to the front end (or whatever other mechanism generates your IR) to ensure that the necessary conventions are correctly followed.

Does that help?

Thanks,

Andy