nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations

Commit d1179c4b apparently causes a ~5% regression in runtime in nofib's cryptarithm1 benchmark. Need to work out why.

Trac metadata

Trac field	Value
Version	8.0.1-rc3
Type	Task
TypeOfFailure	OtherFailure
Priority	highest
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed milestone to %8.0.1

changed weight to 10

added Ttask Trac import labels

Check out allocation figures.. do they budge?

I have not been able to reproduce the regression locally, unfortunately. I did a nofib run prior to merging the commit which as far as I remember didn't show any major regressions; moreover my attempt at reproducing the issue this morning came up (or rather, the change supposedly **improved** runtime by 1.7%, although I don't believe this is significant).

Regardless, according to ghc-speed (which you can reveal by clicking on the = button in the top right corner) the patch didn't change allocations. Judging by the history of this benchmark it seems to be quite unstable. This could be due to a number of things, including caching effects.

changed milestone to %8.0.2

changed weight to 7

Trac metadata

Trac field	Value
Priority	highest → high

closed

This was the change that perf.h.o reported:

nofib/time/cryptarithm1 	0.401	+ 4.99%	0.421	seconds

Since cryptarithm1's runtime is currently under 0.4 seconds again on perf.h.o, I think it's safe to close this ticket, and call it an anomaly.

nofib/time/cryptarithm1 	0.397	=	0.397	seconds

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWorksForMe

added runtime perf label

added Phigh label