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> 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 > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Jul 1, 2008, at 9:45 PM, John Regehr wrote:> 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.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 On Tue, 1 Jul 2008, Chris Lattner wrote:> > On Jul 1, 2008, at 9:45 PM, John Regehr wrote: > >> 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. > > 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >