Hi, at http://hackage.haskell.org/trac/ghc/wiki/Platforms I read, that the Sparc NCG 'is bitrotted' - does that mean, that it is unmaintained, but used by default at sparc? I am asking because the solaris sparc system has a ghc 6.2 installed, which generates .s files. Or does NCG means something else? Regards Georg Sauthoff
On Fri, 2006-06-02 at 15:10 +0200, Georg Sauthoff wrote:
Hi,
at http://hackage.haskell.org/trac/ghc/wiki/Platforms I read, that the Sparc NCG 'is bitrotted' - does that mean, that it is unmaintained, but used by default at sparc?
No it means that GHC uses compilation via C on sparc.
I am asking because the solaris sparc system has a ghc 6.2 installed, which generates .s files. Or does NCG means something else?
When GHC compiles via C, it generates '.hc' files and uses gcc to compile these into assembly '.s' files. When GHC uses its NCG it generates '.s' files directly. In both cases it uses gcc to assemble these '.s' files into object code '.o' files. So if someone were to take up maintainership and fix the bitrotted sparc NCG then we could use -fasm again rather than the default being -fvia-C and benefit from quicker compile times. Duncan
On Fri, Jun 02, 2006 at 03:59:01PM +0100, Duncan Coutts wrote: Hi,
On Fri, 2006-06-02 at 15:10 +0200, Georg Sauthoff wrote:
at http://hackage.haskell.org/trac/ghc/wiki/Platforms I read, that the Sparc NCG 'is bitrotted' - does that mean, that it is unmaintained, but used by default at sparc?
No it means that GHC uses compilation via C on sparc.
ok - after reading http://hackage.haskell.org/trac/ghc/ticket/186 - the Sparc NCG was active until 6.2 and disabled at >= 6.4.
I am asking because the solaris sparc system has a ghc 6.2 installed, [..] So if someone were to take up maintainership and fix the bitrotted sparc NCG then we could use -fasm again rather than the default being -fvia-C and benefit from quicker compile times.
Besides quicker compile times - does the NCG generates better code (more efficient - or is the via -fvia-c generated code less efficient)? Regards Georg Sauthoff
On Mon, 2006-06-12 at 18:38 +0200, Georg Sauthoff wrote:
On Fri, Jun 02, 2006 at 03:59:01PM +0100, Duncan Coutts wrote:
On Fri, 2006-06-02 at 15:10 +0200, Georg Sauthoff wrote:
at http://hackage.haskell.org/trac/ghc/wiki/Platforms I read, that the Sparc NCG 'is bitrotted' - does that mean, that it is unmaintained, but used by default at sparc?
No it means that GHC uses compilation via C on sparc.
ok - after reading http://hackage.haskell.org/trac/ghc/ticket/186 - the Sparc NCG was active until 6.2 and disabled at >= 6.4.
Yeah.
I am asking because the solaris sparc system has a ghc 6.2 installed, [..] So if someone were to take up maintainership and fix the bitrotted sparc NCG then we could use -fasm again rather than the default being -fvia-C and benefit from quicker compile times.
Besides quicker compile times - does the NCG generates better code (more efficient - or is the via -fvia-c generated code less efficient)?
At the moment -fvia-C is produces somewhat faster code than -fasm on all arches. Though the difference varies between arches, I've heard that -fsam is very nearly on par with -fvia-C on x86-64. Historically the main reason for -fasm has been quicker code generation. That's not to say it always has to be that way. The NCGs could be made to use more sophisticated algorithms for various things like register allocation. Duncan
Duncan Coutts wrote:
At the moment -fvia-C is produces somewhat faster code than -fasm on all arches. Though the difference varies between arches, I've heard that -fsam is very nearly on par with -fvia-C on x86-64.
On x86, -fasm is slower for floating point, but probably about the same for integer code. On x86_64, -fasm is about the same as -fvia-C. On powerpc, I believe -fasm is better than -fvia-C. Partly this is because we don't give gcc much room to maneuver. See this wiki page for our long term plan: http://hackage.haskell.org/trac/ghc/wiki/BackEndNotes Basically we want to beef up the NCG and deprecate -fvia-C. Cheers, Simon
Hello Simon, Tuesday, June 13, 2006, 2:18:42 PM, you wrote:
just small note for this page:
The code generated by GHC for a tail-recursive loop uses an explicit tail call for the recursion, which gcc cannot spot as a branch.
gcc can convert recursion into loop and even unroll it. my tests showed that gcc require that THE SAME VARIABLE used in recursion/loop in order to understand that it is indeed a loop. so, the following: while (i>0) { j=i; i=j-1; } will be not considered as loop and unrolled, while the following: a(int i) { if (i>0) a(i-1); } will be tail-recursed and then even unrolled
Basically we want to beef up the NCG and deprecate -fvia-C.
but it still will be used for unregisterised compilation? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (4)
-
Bulat Ziganshin -
Duncan Coutts -
Georg Sauthoff -
Simon Marlow