[LLVMdev] Representing -ffast-math at the IR level

Renato Golin rengolin at systemcall.org
Sat Apr 14 12:23:13 PDT 2012


Hi Duncan,

I'm not sure about this:

+  if (!Accuracy)
+    // If it's not a floating point number then it must be 'fast'.
+    return getFastAccuracy();

Since you allow accuracies bigger than 1 in setFPAccuracy(), integers
should be treated as float. Or at least assert.

Also, I'm thinking you should carry the annotation forward on all uses
of an annotated result, or make sure the floating point library
searches recursively for annotations on any dependency of the value
being analysed.

About creating annotations every time, I think this could be a nice
idea for a metadata factory functionality. Something that would cache
metadata, and in case of repetition, point to the same metadata. This
could be used for other optimisations (if I recall correctly, the
debug metadata does that already).

The problem with this is that, if an optimisation pass changes one,
you must make sure the other can also be changed, or split-on-write,
and that can cause some bloated code in the optimiser, which is not
ideal.

I think, for now, it's acceptable. But should be on request basis
(aka, only present if -fmath options are explicitly specified).

The rest of the patch looks sane, though. I like the idea of using
metadata, since the target code can easily ignore if it doesn't
support FP optimisations or IEEE strictness.

cheers,
--renato



More information about the llvm-dev mailing list