Loop unrolling + fusion ?

Simon Peyton-Jones simonpj at microsoft.com
Tue Mar 10 10:00:58 EDT 2009

| What I don't understand yet is the routemap for replacing -fvia-C

Good points, Claus.  I think the story is as follows:

* -fvia-C does not produce much better code, except in exceptionally tight loops, because GHC gives gcc very little scope for optimisation.  Simon mentioned something like 1% improvement.

* -fvia-C does not give substantially improved portability, because the Evil Mangler must have lots of new (Perl) code for each new platform.  (And each new version of gcc changes the details.)

* -fvia-C does impose maintenance costs, as this thread has rehearsed.

* -fasm has the potential for producing *better* code than gcc, because we can temporarily re-use registers that we must nail down as far as gcc is concerned.

| In other words, what is the plan wrt to backends, especially wrt
| recovering the optimizations and portability issues previously left to
| gcc?

I think you may be over-optimistic about the portability and optimisation benefits. As to other back end plans, it's a fairly active place.  Ben L is doing great stuff on refactoring the native code back end as part of his Sparc NCG.  And John and Norman and I are actively (albeit diverted recently by ICFP submissions) working on getting the refactored STG...flat C-- story into mainstream.


More information about the Glasgow-haskell-users mailing list