I’m losing my sanity, so I thought I’d try and generate an LLVM target for the Glasgow Haskell Compiler (GHC). In talking to some of the people in the GHC mailing list some issues have come up that I can’t find a ready answer to. (Others came up that I could, so I don’t feel quite as stupid or helpless as I could.)
- Is there any way to hint that a global pointer variable should be put in a register when further translated to some native form of code? This is specifically necessary, apparently, for the current stack and heap pointers in GHC for speed reasons.
- This I’m just going to quote: “With (almost) every chunk of code, we want to associate a smal chunk of data (the “info table”) which contains information used by the garbage collector and other parts of the run time system. We want to use only one pointer to point to both of those things, and we don’t want to waste time with any additional indirections, so we make the pointer point between the data chunk and the code chunk.” I’ve asked for clarification on this from the original author, but I suspect it’s something like having a pointer to code base that uses negative offsets to associated data (like some C++ implementations use for the vtable).
- What is the actual support for tail calls? The docs are pretty vague on this point – the “tail” keyword seems to “enable” tail call optimisation. I’m not sure what that means.
- GHC relies an awful lot on having many, many, many “little stacks”. Is it possible to have lots of tiny stacks in LLVM’s architecture, to switch between them easily, to check when they overflow and to automatically grow them when they exceed their bounds?