[PATCH] blockfreq: Rewrite block frequency analysis

[Chandler Carruth]

On Tue, Mar 18, 2014 at 4:52 PM, Andrew Trick <atrick at apple.com> wrote:

> 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?
>

Neither GCC nor LLVM are IEEE 754 compliant host compilers, so I have no
idea how you make this work regardless of the hardware platform. GCC has
recently added a flag aimed at supporting a more strict mode, but it is
quite recent and I have no idea how well the bugs are shaken out. LLVM has
no such flag and is a long way from that conformance.


>
> 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?
>

I actually am interested in this approach and its one of the things that
I've been pondering since reading Duncan's original email.


>
> 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.
>

In a side conversation with Duncan I hinted that I am kind of thinking that
as well. Essentially, it seems increasingly like there is a useful abitrary
precision, accurate, and fast floating point class that could both be used
here with precise semantics and in APFloat's consumers with carefully
twisted semantics to match "hardware behavior". I'm interested in the
potential for layering these things that way, but resistant to starting off
with flat duplication.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140318/f8f36d4b/attachment.html>