HiPE and SIGFPE

[Mikael Pettersson]

On Mon, 14 Aug 2006 14:19:26 +0100, Joel Reymont wrote:
>> Unless you disable floating-point code generation
>> by passing no_inline_fp to the HiPE compiler, HiPE will generate
>> code that relies on the floating-point exception mechanisms in the
>> runtime system.
>
>How does HiPE reply on floating-point exceptions? Does this introduce  
>a significant advantage of some sort?

FP values in Erlang must always be finite, that is, infinities
and not-a-numbers are not allowed. To implement this BEAM includes
a runtime check at the end of each FP operation, to signal badarith
in case of FP errors.

Several years ago BEAM started to optimise FP operations more
seriously. One of the optimisations was to group FP operations
into blocks, which allowed intermediate results to remain untagged
without having to be stored in newly allocated FP terms (boxed).

FP exceptions enables a further optimisation in these blocks.
When an FP exception occurs, a flag is set to record this fact.
If the flag is set at the end of a block of FP operations, we
know that some intermediate operation failed, and we signal badarith.
The optimisation is that we don't have to perform a finiteness
check after each operation, since the hardware does that for us.

So far this is about BEAM. The relationship to HiPE is that since
all major platforms supported by HiPE also support FP exceptions,
we make that a requirement on those platforms rather than an option.
The no_inline_fp HiPE compiler option avoids this requirement, at
the expense of disabling _all_ FP optimisations.

>I have been looking at the code in sys_float.c for several days now  
>and all it seems to do is recover from the exception. It also seems  
>to signal the FP exception to the current process, is that right? Is  
>this the only purpose of handling SIGFPE?

Yes. The exception handler sets the flag that will be inspected at
the end of the current FP block, and then does whatever is necessary
to resume the application. That's all.