I have some issues with representing this as a single "fast" mode flag,
it isn't a single flag, that's the whole point of using metadata. OK, right
now there is only one option (the "accuracy"), true, but the intent is that
others will be added, and the meaning of accuracy tightened, later. MDBuilder
has a createFastFPMath method which is intended to produce settings that match
GCC's -ffast-math, however frontends will be able to specify whatever settings
they like if that doesn't suit them (i.e. createFPMath will get more arguments
as more settings become available).
Note that as the current option isn't actually connected to any optimizations,
there is nothing much to argue about for the moment.
My plan is to introduce a few simple optimizations (x + 0.0 -> x for example)
that introduce a finite number of ULPs of error, and hook them up. Thus this
does not include things like x * 0.0 -> 0.0 (infinite ULPs of error),
reassociation (infinite ULPs of error) or any other scary things.
which mostly boil down to the fact that this is a very C-centric view of the world. And, since C compilers are not generally known for their awesomeness on issues of numerics, I'm not sure that's a good idea.
Having something called a "fast" or "relaxed" mode implies that it is less precise than whatever the standard mode is. However, C is notably sparse in specifying what exactly the standard mode is. The typical assumption is that it is the strict one-to-one translation to IEEE754 semantics, but no optimizing C compiler actually implements that.
I think this is a misunderstanding of where I'm going, see above.
Other languages are more interesting in this regard. Fortran, for instance, allows reassociation within parentheses. (Can that even be represented with instruction metadata?)
I'm aware of Fortran parentheses (PAREN_EXPR in gcc). If it can't be expressed
well then too bad: reassociation can just be turned off and we won't optimize
Fortran as well as we could. (As mentioned above I have no intention of turning
on reassociation based on the current flag since it can introduce an unbounded
number of ULPs of error).
OpenCL has a very fairly baseline mode, but specifies a number of specific options the user can enable to relax it (-cl-mad-enable, -cl-no-signed-zeros, -cl-unsafe-math-optimization (implies the previous two), -cl-finite-math-only, -cl-fast-relaxed-math (implies all prior)). GLSL has distinct desktop and embedded specifications that place different levels of constraint on implementations.
If we define the baseline behavior to be strict IEEE conformance,
Which we do.
and then don't provide a more nuanced method of relaxing it,
Allowing more nuanced ways is the reason for using metadata as explained above.
we're not going to be in a significantly better world than we are today. No reasonable implementation of these languages wants strict conformance (except maybe desktop-profile OpenCL) as their default mode,
Strict conformance is what they get right now.
nor is there any way a universal definition of "fast" math can work for all of them.
I agree, and I'm not trying to provide one.