On 5 July 2011 11:55, Simon Marlow <[email protected]> wrote:
> I'm officially on holiday hence the brief response.  I'm fairly sure this
> should be safe, yes.

Thanks for taking time out of your holiday to reply! I'll push that patch then.

Once you are back from holiday, could you sanity check the below idea
for reducing exports further:

== The Idea ==

For nullary data constructors, we currently avoid exporting the
_con_info and _info pointers. However, we *still* export the
_static_info pointer for use when building a statically allocated
top-level instance of that DataCon in another module.

The observation is that we don't actually need the _static_info
pointer to fulfil this use case. Ideally, when building e.g.
otherwise_closure we would just insert an ".alias otherwise_closure
True_closure" directive into the generated ASM, avoiding any code
generation and forwarding the export to the existing closure.

In practice, aliasing directives like this are not portable
(apparently Mach-O does not support aliasing at all, and I can't see
how to persuade the -fvia-c backend to generate a .alias via GCC), so
I wrote a patch that used an alternative idea. The idea is to generate
a closure for otherwise_closure that is a statically allocated
indirection to the exported True_closure.

My patch to do this is below, but the code it generates segfaults very
quickly :-(

I'm fairly sure this is because I've screwed up some aspect of how
indirections are represented, or perhaps misunderstood the meaning of
IND_STATIC (which appears to only be used in blackholing CAFs at the
moment). I'd appreciate it if you (or anyone else knowledgable!) could
sanity check my new implementation of cgTopRhsCon in the attached
code.

Cheers,
Max

Attachment: static_info.diff
Description: Binary data

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to