Opened 18 months ago

Last modified 10 months ago

#8901 infoneeded bug

(very) bad inline heuristics

Reported by: heisenbug Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

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 (7)

comment:1 Changed 18 months 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 Changed 18 months 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 18 months 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 18 months 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 18 months 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 18 months 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 10 months ago by thomie

  • Status changed from new to infoneeded
Note: See TracTickets for help on using tickets.