GHC API: Access to nativeCodeGen?

[Peter A Jonsson]

> > I had perl 5.005_03 first in my path, that made the splitter not
> > work. Changing to a newer version made it work. Maybe a test could be
> > added to configure to avoid too old versions of perl?
> 
> I'll be happy to - but I don't know exactly what version of Perl we
> require.  Any clues?  What went wrong with the splitter?

Sorry for the bad description of the error. I'll try again: The
problem I had was a failed build and a silent failure of the
splitter. No error message or similar, just a return. Poking around
with it and running "perl splitter <args..>" manually gave a core dump
from 'perl'.

It didn't complain about parse errors or similar so my guess is that
the code in itself is 5.005_03-compatible, the splitter is just
triggering some bug in the perl machinery. I didn't think of writing
down any details at the moment since changing to 5.8.4 'fixed' my
problem.

Perl 5.6.0 seems to be released 2000-Mar-22, demanding that people who
build ghc have a perl that is no older than 5 years might be a
reasonable first step?

> > Needed a patch to build NCG. I tried to preserve as much of the
> > previous structure in order to avoid introducing bugs, but I wasn't
> > entirely successfull. I've attached the patch and would appreciate if
> > someone could glance over it looking for obvious errors.
> 
> There are never any "obvious" errors in the NCG :-)  I did glance over
> it, and it mostly looks like a straightforward change over to Cmm.
> Since your patch only touches code inside #ifdef sparc_TARGET_ARCH,
> which is currently broken anyway, I'm inclined to just merge it as-is.

That sounds good to me, a smaller diff would hopefully make my life
easier. 

About the lack of sparc-support - is the problem that no active
developers have access to sparc-machines any longer or is there simply
no interest in sparc? If it is the former, contact me off list and
I'll try to help out.

> > With this patch a bunch of array tests with WAY=normal fails, all in
> > the same way:
> > 
> > Stack space overflow: current size 8388608 bytes.
> > Use `+RTS -Ksize' to increase it.
> 
> Best guess is the code generated for a stack-check sequence is
> incorrect.  Match up the assembly file (use -keep-s-file) with the Cmm
> (-ddump-opt-cmm) and see if you can spot the incorrect code.  I can
> provide some gdb tips - let me know if you need more help.

Ahh, and here I was using -v5. This is much better.

The stack-check sequence you are referring to, is that in Cmm
represented by "if ((Sp + -12) < SpLim) goto <label>"? If that is the
case, I can't find any errors in the asm produced. 

Any hints that would ease the burden of reading big chunks of
assembler would be much appreciated!

> Also, the codeGen tests are probably a better place to start
> (tests/ghc-regress/codeGen/should_run).

Ok, will look into this.

/ Peter