stg_ap_v_ret porting crash: solved?

[Simon Marlow]

> Am I right in thinking that by just putting
> 
> GhcUnregisterised=YES
> SplitObjs=NO
> 
> in mk/build.mk every time you build GHC it ought to not only work on
> arches with bit-rotted mangler support but also those with none
> attempted? Where work means compiles the same set of programs, but the
> result (as well as the compilation) will be slower?

Yes, with the caveat that this applies only to the the code *generated*
by the GHC you're building.

> Starting with a reg compiler producing reg code and iterating 
> a standard
> configure/make/make install with 6.0.1 gives these numbers on x86:
> 
> 70m5.850s
> 86m27.550s
> 86m26.350s
> 
> so it looks like this is about 25% slower, although I don't know how
> much it will vary by architecture. This isn't purely testing GHC of
> course, but I think it's probably pretty close.

Interesting.  Bear in mind that a lot of the time is spent in GCC, and
that is going to be roughly the same for registerised vs.
unregisterised, so overall compile times don't look much different.
However, I think you'll find that ordinary Haskell programs will vary by
about a factor of 2 in performance between registerised & unregisterised
(last time I checked was a few years ago, though).

What are the binary sizes like?

> This seems better than no GHC at all for unsupported arch/OS
> combinations, and I unfortunately don't have the time to learn the
> details of what needs to be done and all the assembly languages and
> calling conventions that Debian supports.
> 
> It would also mean that anyone who does want to try to get it working
> registerised on an arch could skip the cross-porting stage.

Sure, shipping an unregisterised port is completely acceptable.

> Incidentally, it looks to me like the comment
> 
> # NOTE: this is not the same as building the compiler itself
> # unregisterised.  That's done by either (a) bootstrapping with a
> # compiler that was built with GhcUnregisterised=YES, or (b)
> # bootstrapping with a compiler that has way 'u' libraries, and the
> # flag '-unreg' is added to GhcHcOpts above.
> 
> about GhcUnregisterised in mk/config.mk is outdated given the 2-stage
> building process that is now the default?

Hmm, I should update that comment.

Cheers,
	Simon