Opened 2 years ago

Last modified 6 months ago

#8901 infoneeded bug

(very) bad inline heuristics

Reported by: heisenbug Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: Cc: erikd
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I observe a bad case for inlining blowup for the time library. Observed for 7.7, just checked in 7.9.

The problem is so bad that the PowerPC32 assembler cannot resolve cross-routine references. (I have no error message at hand, but could try to get one.)

Instead here are the stats for x86, with inlining and certain inlining suppressed. The architecture seems irrelevant.

$ file ./libraries/time/dist-install/build/Data/Time/Format.o
./libraries/time/dist-install/build/Data/Time/Format.o: Mach-O object i386

$ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*
-rw-r--r--  1 ggreif  staff   61875 Mar 15 16:48 ./libraries/time/dist-install/build/Data/Time/Format.dyn_hi
-rw-r--r--  1 ggreif  staff  450864 Mar 15 16:48 ./libraries/time/dist-install/build/Data/Time/Format.dyn_o
-rw-r--r--  1 ggreif  staff   61863 Mar 15 16:48 ./libraries/time/dist-install/build/Data/Time/Format.hi
-rw-r--r--  1 ggreif  staff  332216 Mar 15 16:48 ./libraries/time/dist-install/build/Data/Time/Format.o

With following patch applied:

<https://github.com/ggreif/packages-time/commit/83f08b8896b950707a910fed4e30bddb7ee7f52f>

I get:

$ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*
-rw-r--r--  1 ggreif  staff   10554 Mar 16 00:08 ./libraries/time/dist-install/build/Data/Time/Format.dyn_hi
-rw-r--r--  1 ggreif  staff  106832 Mar 16 00:08 ./libraries/time/dist-install/build/Data/Time/Format.dyn_o
-rw-r--r--  1 ggreif  staff   10542 Mar 16 00:08 ./libraries/time/dist-install/build/Data/Time/Format.hi
-rw-r--r--  1 ggreif  staff   78864 Mar 16 00:08 ./libraries/time/dist-install/build/Data/Time/Format.o

The factor is 4.2 for Format.o, Format.dyn_o and 5.8 for the .hi files.

Change History (10)

comment:1 Changed 2 years ago by Ashley Yakeley

It's not clear to me whether this should be considered a bug in the time library or a bug in GHC.

comment:2 in reply to: ↑ description ; follow-up: Changed 2 years ago by trommler

Replying to heisenbug:

The problem is so bad that the PowerPC32 assembler cannot resolve cross-routine references. (I have no error message at hand, but could try to get one.)

FWIW The powerpc issue in the time library (#7830) was fixed by @erikd.

comment:3 follow-up: Changed 2 years ago by simonpj

Can you explain what the bug in GHC is? And (as Ashley asks) why you believe it's a bug in GHC and not the library?

comment:4 in reply to: ↑ 3 Changed 2 years ago by heisenbug

Replying to simonpj:

Can you explain what the bug in GHC is? And (as Ashley asks) why you believe it's a bug in GHC and not the library?

It is hard to pinpoint. There has been some rope-pulling between me and Ashley (on the dev list/in private) as he has not been keen of accepting my patch (so far) asking whether it could be a GHC bug. I tend to agree, as a quality inliner should not attempt to inline (e.g.) formatTime which has 8 alternatives and is called from 10+ sites. It would be interesting to see whether any bloat-controlling measures failed detecting this case, esp. as Format.hs appears to be a relatively benign source file. Some lessons might be learnt from this.

OTOH, a library author should keep in eye how popular compilers digest the lib.

I am ending up stuck between a rock and a hard place.

comment:5 Changed 2 years ago by Ashley Yakeley

The problem is so bad that the PowerPC32 assembler cannot resolve cross-routine references. (I have no error message at hand, but could try to get one.)

This might be helpful. If GHC cannot compile a correct program with a correct time library to PowerPC32, that would surely be a bug in GHC, would it not?

comment:6 Changed 2 years ago by simonpj

Not necessarily. It's not hard to give GHC a heart attack by inlining too aggressively.

If you can exhibit a case where you think GHC is inlining where it shouldn't I'll gladly look at it. For example you mention formatTime; can you give a test case? Eg a test file with 10+ calls, that all inline when they shouldn't?

Simon

comment:7 Changed 21 months ago by thomie

  • Status changed from new to infoneeded

comment:8 in reply to: ↑ 2 Changed 11 months ago by heisenbug

Replying to trommler:

Replying to heisenbug:

The problem is so bad that the PowerPC32 assembler cannot resolve cross-routine references. (I have no error message at hand, but could try to get one.)

FWIW The powerpc issue in the time library (#7830) was fixed by @erikd.

But that bug (#7830) is not closed yet!

comment:9 Changed 11 months ago by erikd

  • Cc erikd added

#7830 was closed for some time, but was re-opened just recently.

comment:10 Changed 6 months ago by thomie

  • Type of failure changed from None/Unknown to Runtime performance bug
Note: See TracTickets for help on using tickets.