Speculative execution of FP divide Instructions - Call-Graph Simplify

[+current llvm-dev address]

Thank you all for the responses!

I understand that FP exceptions are activated programatically and can be disabled. I guess my point is that those divisions can have side effects and the compiler can’t prove they have not. I imagine that, from a user viewpoint, if I write code like:

double a, b, c

if (a > b)
c = a/b

thinking that my conditional also guards against divisions by zero, and activate the exceptions exactly to assert that, transformations that speculate the execution of the divisions won’t serve me well. The whole purpose of having FP exception support just vanishes.

I guess that at the end of the day this is about choosing what is a “good” default behaviour. I don’t feel strongly one way or the other, just thought that this deserved some discussion.

I don’t think this is what Andrew is trying to solve, is it? Exceptions can be activated anywhere, not necessarily in the same compilation unit.

Thanks again!
Samuel

I’d imagine it’s very difficult for compiler to track FP exception control (unless it actually inserts fegetenv calls to get control bits at runtime :/).
I think Hal was pointing out that straight-lining fp division is very rare thing given that it is very expensive in many target architectures. It probably means that cost model is whacky somewhere.

Kevin

The point is that they should be disabled by default. If you enable them, you need to tell the compiler you’ve done so (using a command-line option or #pragma STC FENV_ACCESS ON). Otherwise, the compiler gets to assume that they’re off. We currently don’t support anything else. When we support a mode where FP exceptions are enabled, we’ll disable such transformations (as we’re currently working on doing this, with special intrinsics for the FP operations in these modes, we get a lack of this kind of speculation naturally). You should be able to use the FENV_ACCESS pragma to turn these on/off even within the same translation unit. -Hal