RE: GHC API: Access to nativeCodeGen?
On 18 July 2005 12:01, Peter A Jonsson wrote:
Ok, I gave it a spin, that was "interesting". Things I wrote down while looking at it that might be of interest to others:
I tried to build with gcc 3.4.1 and it didn't work very well. Found a mail from November 2004 (<Message-Id: 419B599C.2020204@tzi.de>) which had the same problem. In a reply you said that it was the JMP_-macro in TailCall.h and changing the cast would make the warning go away. It did, however I think I messed up with something else since it made other problems appear. I reverted my changes and switched gcc instead.
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?
All those "Bad eta expand" looks slightly scary when building for the first time. Found a mail from Simon Peyton Jones which made me less worried. Maybe it could be documented that those are expected in the building guide?
Ok, we'll look into sqashing those.
The GHC commentary was written for pre-CMM NCG. I tried patching that while going through the code but I just ended up butchering the document to basically contain no information whatsoever. I'm not sure it's helpful at all in its current shape though, unfortunately.
True - I'd love to update this, but quite gigantic. A shame that Julian put so much effort into writing this doc, and it's now mostly out of date (and I don't think I even referred to it once when converting the NCG to Cmm :-().
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.
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. Also, the codeGen tests are probably a better place to start (tests/ghc-regress/codeGen/should_run). Cheers, Simon
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
participants (2)
-
Peter A Jonsson -
Simon Marlow