[PATCH] blockfreq: Rewrite block frequency analysis
atrick at apple.com
Wed Mar 19 00:10:24 PDT 2014
On Mar 18, 2014, at 11:53 PM, Duncan P. N. Exon Smith <dexonsmith 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 was concerned about determinism and portability, but I hadn’t
> thought about it much. I just assumed floats were off-limits.
> If hardware floats are an option, a long double is almost a drop-in
> replacement for PositiveFloat, surely faster, and a negligible
> maintenance burden. I don’t know enough about portability to make
> a call on that, though.
(long double) is not going to be portable. When I made the comment above, I was assuming we would cast everything to (double), which I *thought* would be portable with SSE+ and other platforms we commonly build on. i.e. we get the same rounding on all builders as long as they don’t use -ffast-math or -Ofast. My question should have been phrased “is double sufficient for our purpose?”.
I’ve also been assuming floats are off-limits, but can no longer remember any good reason other than x87. It sounds like Chandler knows of some other practical issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits