On 6 July 2011 12:22, Simon Marlow <[email protected]> wrote:
> So I'm not sure it's worth the hassle of dealing with platform-specific
> low-level stuff for this case, since we don't save many symbols - there
> aren't many nullary constructors compared to, say, thunks or function
> closures.
The idea behind using a statically allocated indirection was to avoid
the use of symbol aliases at the assembly-language level: it should be
a portable solution.
This would save many more symbols than you might think: GHC would
export 1538 less symbols! This originate from e.g. enumerations of the
primops, lexer lexemes, LLVM base types, types of conditional flag in
the X86 backend, the dynflags.. etc etc. So I really think it is worth
pursuing this change. Is there anything obviously wrong with the patch
as you see it?
== New Idea ==
I've also come up with another way we could reduce the number of
exports: data constructors needn't export their _info pointers. The
reason is that GHC invariably eta-expands data constructor
applications to their maximum arity, so the use site code is always
generated directly as allocated a dyn closure using the _con_info
symbol.
You can see this behaviour like so:
"""
$ cat DC.hs
module DC where
static_not_app = Just
static_pap = (,) 1
static_full_ap = Left 1
foo x = (dynamic_pap, dynamic_full_ap)
where
-- dynamic_not_app would just be floated
dynamic_pap = (,) x
dynamic_full_ap = Left x
$ ghc -c -ddump-stg -ddump-cmm DC.hs
==================== STG syntax: ====================
DC.foo =
\r [x_srR]
let { sat_srU = NO_CCS Data.Either.Left! [x_srR]; } in
let { sat_srV = \r [eta_B1] (,) [x_srR eta_B1];
} in (,) [sat_srV sat_srU];
SRT(DC.foo): []
a_rrN = \u srt:(0,*bitmap*) [] GHC.Integer.smallInteger 1;
SRT(a_rrN): [GHC.Integer.smallInteger]
DC.static_full_ap = NO_CCS Data.Either.Left! [a_rrN];
SRT(DC.static_full_ap): []
a1_rrP = \u srt:(0,*bitmap*) [] GHC.Integer.smallInteger 1;
SRT(a1_rrP): [GHC.Integer.smallInteger]
DC.static_pap = \r srt:(0,*bitmap*) [eta_B1] (,) [a1_rrP eta_B1];
SRT(DC.static_pap): [a1_rrP]
DC.static_not_app = \r [eta_B1] Data.Maybe.Just [eta_B1];
SRT(DC.static_not_app): []
"""
Furthermore, there are no Just_info pointers imported by any object
file generated by GHC. So I really think this is already an invariant
of the generated source code (I think it is ensured by
CorePrep.cpeApp), but before committing any change along these lines I
think I would have to go through and carefully document this to make
sure it isn't broken in the future.
Max
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
