[PATCH] Short-term workaround for hidden x86 float precision in calculateSpillWeightAndHint()
Duncan P. N. Exon Smith
dexonsmith at apple.com
Mon Apr 21 11:04:48 PDT 2014
On 2014-Apr-21, at 10:15, Andrew Trick <atrick at apple.com> wrote:
>
> On Apr 21, 2014, at 9:39 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>
>> The attached patch is a workaround that prevents hidden precision from
>> changing results in x86 floats in calculateSpillWeightAndHint().
>>
>> Applying my BlockFrequencyInfo patch causes two test failures on i386
>> (see, e.g., r206704). My patch changes the output of the pass, and
>> somehow exposes this problem in calculateSpillWeightAndHint(). In
>> the affected code:
>>
>> float hweight = Hint[hint] += weight;
>> if (TargetRegisterInfo::isPhysicalRegister(hint)) {
>> if (hweight > bestPhys && mri.isAllocatable(hint))
>> bestPhys = hweight, hintPhys = hint;
>> }
>>
>> I converted `hweight` and `bestPhys` to APFloat and used
>> APFloat::toString() to dump them. In the problematic code path, they
>> are both exactly equal to 1. However, the comparison
>> `hweight > bestPHys` gives `true` due to hidden precision in x86.
>> Marking `hweight` as `volatile` forces it to be a stack variable
>> (preventing hidden precision), so this comparison correctly gives
>> `false` even on i386 (hack suggested by chapuni!).
>>
>> This is an awkward workaround. There seem to be 4 possible fixes
>> here, so let me enumerate them:
>>
>> 1. Mark `hweight` as `volatile` (attached patch). This is a very
>> quick fix that unblocks my BlockFrequencyInfo work, but if adopted
>> should be revisited afterwards. In particularly, I'll yell FIXME
>> somewhere and reference the *right* fix.
>
> That’s fine to unblock your work.
r206765
More information about the llvm-commits
mailing list