stg_ap_v_ret porting crash: solved?
simonmar at microsoft.com
Mon Sep 15 16:18:43 EDT 2003
> Am I right in thinking that by just putting
> 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:
> 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.
More information about the Glasgow-haskell-users