Although the process of porting the LLVM backend to a new architecture looks pretty straightforward (and is very well documented) there's a frontend issue that I'm not clear on:
How do we to tell the frontend about implementation-defined constants like integer width? In other words, when llvm-gcc does a promote-to-integer operation, this acts differently if the target architecture has 16-bit vs 32-bit integers.
Thanks,
John Regehr
There was a recent discussion about this specific issue. We need to eliminate the implicit sign/zero extend to 32 bit logic from the code generator and have the front-ends insert them.
-Chris
Thanks Chris. I'll follow any ongoing discussion about this. Unless I'm missing something, customizable widths for integer types is necessary to achieve source-level compatibility with existing cross-compilers.
It would be great to see the fronend being parameterized by integer widths at runtime. There would be no noticable loss of efficiency and this would avoid the obnoxious and error-prone situation of keeping many C frontends sitting around.
FWIW CIL just lately became parameterizable at runtime with machine-specific information and it's really handy.
John
Hi John,
Just to be clear, LLVM fully supports cross compilation. This issue is a problem for LLVM generating code for any target where sizeof(int) != 32, regardless of whether you are natively compiling or cross compiling. The previous discussion was in the context of the PIC port.
If you follow the thread, you'll see that this is really easy to fix and only impacts promotion of return values. LLVM fully supports your front-end mapping int/long/etc onto whatever size integer you want, this is only specific to the one case of return value promotion.
-Chris
Got it-- thanks Chris.
John