32-bit Linux perf failures

[Mateusz Kowalczyk]

On 20/02/14 10:40, Joachim Breitner wrote:
> Hi,
> 
> Am Donnerstag, den 20.02.2014, 01:39 +0000 schrieb Mateusz Kowalczyk:
>> I just ran validate with current HEAD
>> (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf
>> failures. Perhaps these need tweaking? I know that 32-bit numbers were
>> neglected in the past. The Haddock numbers have been complaining for a
>> few weeks now but I think everything else is fairly new.
>>
>> Here is the end of the log:
>>
>> Unexpected results from:
>> TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal
>> haddock.compiler haddock.base T3924"
> 
> Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the
> change for 32bit is expected, just update the numbers to what your
> computer says) and T3924 was added by my without 32bit numbers (so add
> your numbers, after adding the usual bitness-switch). Also T4267 is
> lacking 32-bit numbers.
> 
> Generally, you might want to run "git blame" on the all.T-files and see
> if there was a recent change to the 64 bit numbers in the same direction
> than the change you are observing, and in that case simply update the
> numbers accordingly.
> 
> 
> Maybe when changing the 64-bit number we should have a way of marking
> the i386 as likely out of date, so that the next person on 32bit will
> see a message „Number changed, but that’s expected, so please just
> update all.T“.
> 
> Greetings,
> Joachim
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

While I technically have the push permissions, I'm not a GHC dev. I feel
like it'd be inappropriate to push in such a ‘fix’ myself. I can post a
full validate log if that contains information one would need to update
the numbers.

Even if I wanted to, I have no idea how to go about updating the
numbers! Is there a guide of some sort available? I was unable to find
anything.

Thanks

-- 
Mateusz K.