Opened 3 years ago

Last modified 3 years ago

#13213 new task

Lifting thunks out of thunks to reduce their size.

Reported by: nomeata Owned by:
Priority: low Milestone:
Component: Compiler Version: 8.0.1
Keywords: Cc: rwbarton, simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

This is a spin off of this thread: ticket:10980#comment:12

The idea is to add a transformation to STG (or Core) that replaces

let t1 = let t2 = e1
         in e2
in e3

with

let t2 = e1 
    t1 = e2
in e3

Can we give an easy criterion when this transformation is beneficial?

The problem is that this will increase allocation in the case when t1 is not called, as it is more space efficient to pack the union of the free variables of e1 and e2 into one closure, instead of having one for the free variables of e1 and one for those of e2.

We could say “Do this transformation if the free variables of e2 and e1” are disjoint. Then we’d allocate two extra words (one for the info table of t2, and one pointer to that in the closure for t1), but have some nice gains if t1 is indeed called.

But this rule would not fire in the original example, because the Num a dictionary is also a free variable, which would now have to be copied into both closures!

I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between e1 and e2 are heuristically ok.

Change History (3)

comment:1 Changed 3 years ago by rwbarton

Copying the original example here for visibility, the issue (bug?) is that the (polymorphic in Num) function f defined by

f a1 a2 a3 a4 a5 a6 a7 a8 a9 a10
  = a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10

has quadratic code size and runtime allocations in the number of arguments (here 10).

Last edited 3 years ago by rwbarton (previous) (diff)

comment:2 Changed 3 years ago by rwbarton

Anecdotally it's fairly common to see ugly long strings of mov instructions in generated code, though I don't know whether they are from cases like this one, the similar but distinct case of ticket:10980#comment:13, or something completely different like record updates in a record with many fields.

comment:3 Changed 3 years ago by simonmar

Cc: simonmar added
Note: See TracTickets for help on using tickets.