stg_ap_v_ret porting crash: solved?

[Ian Lynagh]

On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote:
>  
> Looks like you need some mangler support now...

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?

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.

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.

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?


Thanks
Ian