Add option to give each usage of a data constructor its own info table

The `-fdistinct-constructor-tables` flag will generate a fresh info
table for the usage of any data constructor. This is useful for
debugging as now by inspecting the info table, you can determine which
usage of a constructor caused that allocation rather than the old
situation where the info table always mapped to the definition site of
the data constructor which is useless.

In conjunction with `-hi` and `-finfo-table-map` this gives a more fine
grained understanding of where constructor allocations arise from in a
program.

1 files changed, 0 insertions, 74 deletions

diff --git a/compiler/GHC/Driver/CodeOutput.hs b/compiler/GHC/Driver/CodeOutput.hs
index f6b9e9738c..5e0c5f0c05 100644
--- a/compiler/GHC/Driver/CodeOutput.hs
+++ b/compiler/GHC/Driver/CodeOutput.hs
@@ -353,77 +353,3 @@ ipInitCode dflags this_mod ents
       <> semi
 
 
-{-
-Note [Mapping Info Tables to Source Positions]
-
-This note describes what the `-finfo-table-map` flag achieves.
-
-When debugging memory issues it is very useful to be able to map a specific closure
-to a position in the source. The prime example is being able to map a THUNK to
-a specific place in the source program, the mapping is usually quite precise because
-a fresh info table is created for each distinct THUNK.
-
-There are three parts to the implementation
-
-1. In CoreToStg, the SourceNote information is used in order to give a source location to
-some specific closures.
-2. In StgToCmm, the actually used info tables are recorded.
-3. During code generation, a mapping from the info table to the statically
-determined location is emitted which can then be queried at runtime by
-various tools.
-
--- Giving Source Locations to Closures
-
-At the moment thunk and constructor closures are added to the map. This information
-is collected in the `InfoTableProvMap` which provides a mapping from:
-
-1. Data constructors to a list of where they are used.
-2. `Name`s and where they originate from.
-
-During the CoreToStg phase, this map is populated whenever something is turned into
-a StgRhsClosure or an StgConApp. The current source position is recorded
-depending on the location indicated by the surrounding SourceNote.
-
-The functions which add information to the map are `recordStgIdPosition` and
-`incDc`.
-
-When the -fdistinct-constructor-tables` flag is turned on then every
-usage of a data constructor gets its own distinct info table. This is orchestrated
-in `coreToStgExpr` where an incrementing number is used to distinguish each
-occurrence of a data constructor.
-
--- StgToCmm
-
-The info tables which are actually used in the generated program are recorded during the
-conversion from STG to Cmm. The used info tables are recorded in the `emitProc` function.
-All the used info tables are recorded in the `cgs_used_info` field. This step
-is necessary because when the information about names is collected in the previous
-phase it's unpredictable about which names will end up needing info tables. If
-you don't record which ones are actually used then you end up generating code
-which references info tables which don't exist.
-
--- Code Generation
-
-The output of these two phases is combined together during code generation.
-A C stub is generated which
-creates the static map from info table pointer to the information about where that
-info table was created from. This is created by `ipInitCode` in the same manner as a
-C stub is generated for cost centres.
-
-This information can be consumed in two ways.
-
-1. The complete mapping is emitted into the eventlog so that external tools such
-as eventlog2html can use the information with the heap profile by info table mode.
-2. The `lookupIPE` function can be used via the `whereFrom#` primop to introspect
-information about a closure in a running Haskell program.
-
-Note [Distinct Info Tables for Constructors]
-
-In the old times, each usage of a data constructor used the same info table.
-This made it impossible to distinguish which actual usuage of a data constructor was
-contributing primarily to the allocation in a program. Using the `-fdistinct-info-tables` flag you
-can cause code generation to generate a distinct info table for each usage of
-a constructor. Then, when inspecting the heap you can see precisely which usage of a constructor
-was responsible for each allocation.
-
--}