[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