Opened 3 years ago

Last modified 13 days ago

#7198 new bug

New codegen more than doubles compile time of T3294

Reported by: simonmar Owned by: simonmar
Priority: normal Milestone:
Component: Compiler (CodeGen) Version: 7.4.2
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: #4258 Differential Rev(s):
Wiki Page:


I did some preliminary investigation, and there seem to be a couple of things going on.

First, the stack allocator generates lots of unnecessary reloads at a continuation, for variables that are not used. These would be cleaned up by the sinking pass (if we were running the sinking pass), but generating them in the first place costs compile time.

Second, there is a large nested let expression of the form

let x = let y = let z = ...
                in  f z
        in  f y

where each let binding has a lot of free variables. So the body of each let ends up copying a ton of variables out of its closure to build the inner let binding's closure. These sequences look like:

x1 = [R1+8]
x2 = [R1+16]
[Hp-32] = x1
[Hp-24] = x2

now CmmSink can't currently inline all the locals because knowing that [R1+8] doesn't alias [Hp-32] is tricky (see comments in CmmSink). However, again, we're not even running the sinking pass because this is -O0. The fact that we generate all this code in the first place is a problem. The old code generator generated

[Hp-32] = [R1+8]
[Hp-24] = [R1+16]

which amounts to a lot less Cmm, and a lot less trouble for the register allocator later.

One thing we could do is flatten out the lets, on the grounds that the inner let binding has a lot of free variables that need to be copied when the let is nested. This could be based on a heuristic about the number of free variables and the amount of extra allocation that would be entailed if the let is never entered.

Change History (6)

comment:1 Changed 22 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

Bumping priority down (these tickets haven't been closely followed or fixed in 7.4), and moving out to 7.10 and out of 7.8.3.

comment:2 Changed 22 months ago by thoughtpolice

  • Priority changed from high to normal

Actually dropping priority. :)

comment:3 Changed 14 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:4 Changed 11 months ago by thomie

  • Cc simonmar added
  • Component changed from Compiler to Compiler (CodeGen)
  • Type of failure changed from None/Unknown to Compile-time performance bug

comment:5 Changed 5 months ago by thoughtpolice

  • Milestone changed from 7.12.1 to 8.0.1

Milestone renamed

comment:6 Changed 13 days ago by thomie

  • Milestone 8.0.1 deleted
Note: See TracTickets for help on using tickets.