[PATCH] blockfreq: Rewrite block frequency analysis
atrick at apple.com
Tue Mar 18 16:52:36 PDT 2014
On Mar 17, 2014, at 8:33 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> I share Bob's concern about PositiveFloat -- I'm worried about introducing a second quite complex floating point class with subtle and untest differences from APFloat. This is especially true if one cannot be implemented in terms of the others.
> As I mentioned in response to Bob’s review, I’ll see if there are
> performance reasons to use this. It really is much simpler than APFloat,
> but a wrapper around APFloat is even simpler.
I'd like to see the motivation for avoiding native floating point reiterated. Are we just concerned about determinism across non-754-compliant platforms, or is IEEE 754 insufficient for our needs? If it's just non-compliant platforms, then how many people care if an x87 build generates different code?
I know that so far our attempts to work around using a floating-point representation in ad-hoc ways have led to madness. But, it is worth asking one more time: can we avoid running into the dynamic range by artificially limiting the loop scale? i.e. one we know all the scales, is it possible to adjust them to avoid overflow?
Assuming we need soft-float, I'm sure you'll be able to demonstrate the performance advantage over APFloat. Using PositiveFloat might even generate a smaller dynamic footprint than reusing APFloat.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits