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