[GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag

[GHC]

#15548: Make TABLES_NEXT_TO_CODE a dynflag
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:
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 changed by nomeata:

Old description:

> The GHC API is used by programs that do not necessarily want to compile
> the same way as the normal GHC, so we want as much configuration in
> `DynFlags` and as little as possible hard-coded.
>
> One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used
> in these places:
>
>  * It is (of course) used a lot in rts. That’s fine.
>  * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code,
> so that code is already prepared to read the information from `DynFlags`.
>  * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some
> refactoring there might be needed to add a `DynFlag` there.
>
> (The motivation is similar to #13477)

New description:

 The GHC API is used by programs that do not necessarily want to compile
 the same way as the normal GHC, so we want as much configuration in
 `DynFlags` and as little as possible hard-coded.

 One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in
 these places:

  * It is (of course) used a lot in rts. That’s fine.
  * It is used via `tablesNextToCode :: DynFlags -> Bool` in the Cmm code,
 so that code is already prepared to read the information from `DynFlags`.
  * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some
 refactoring there might be needed to add a `DynFlag` there.

 (The motivation is similar to #13477)

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15548#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler