Peter, Thanks! Do you happen to know where this needs to be changed in clang or LLVM. The code that actually interprets the constraints, generically, is in CodeGen/SelectionDAG/TargetLowering.cpp, is clang relying on that code, or is there some frontend code in clang itself that is failing to initially interpret the string? If it is the code in TargetLowering, then I don't see any support there for '*' or '#'. -Hal On Fri, 27 Apr 2012 19:33:58 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote:> On Fri, 2012-04-27 at 14:54 -0500, Hal Finkel wrote: > > There is a comment in the file which reads: > > > > /* The weird 'i#*X' constraints on the following suppress a gcc > > warning when __excepts is not a constant. Otherwise, they mean > > the same as just plain 'i'. */ > [sinp] > > ("mtfsb0 %s0" : : "i#*X"(__builtin_ffs (__excepts))); > [snip] > > Does anyone know what that "weird" asm constraint actually means? > > > The "i" and "X" constraints are documented here: > > http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Simple-Constraints.html > > `i' > An immediate integer operand (one with constant value) is allowed. > This includes symbolic constants whose values will be known only > at assembly time or later. > > `X' > Any operand whatsoever is allowed. > > > The # and * constraint modifiers are documented here: > > http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Modifiers.html > > `#' > Says that all following characters, up to the next comma, are to > be ignored as a constraint. They are significant only for choosing > register preferences. > > `*' > Says that the following character should be ignored when choosing > register preferences. `*' has no effect on the meaning of the > constraint as a constraint, and no effect on reloading. > > For more info about PowerPC specific constraints, you'll want to look > here: > > http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Machine-Constraints.html > > > I'll note that the "s" in the %s0 means to only print the low 5 bits > of operand 0. I think that may only be documented in the src: > > gcc/config/rs6000/rs6000.c:print_operand() > > > Peter > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Fri, 2012-04-27 at 20:30 -0500, Hal Finkel wrote:> Thanks! Do you happen to know where this needs to be changed in clang > or LLVM. The code that actually interprets the constraints, > generically, is in CodeGen/SelectionDAG/TargetLowering.cpp, is clang > relying on that code, or is there some frontend code in clang itself > that is failing to initially interpret the string? If it is the code in > TargetLowering, then I don't see any support there for '*' or '#'.Heh, I'm afraid I have no clue as to where clang needs to be changed. I'm the team lead for IBM's Linux on POWER GCC development team, so I can help you with questions about PPC hardware, PPC ABIs and why GCC does things the way it does on PPC, but I'll not be of much help with LLVM itself. I'm just a lurker here. :) That said, I'm curious about the extent of LLVM's support for PPC. How robust is it? Does it support generating both 32-bit and 64-bit binaries? I'll note that although I work on GCC, I have no problems seeing LLVM supporting PPC. The more the merrier. Peter
Richard Pennington
2012-Apr-28 16:58 UTC
[LLVMdev] [cfe-dev] Odd PPC inline asm constraint
On Saturday, April 28, 2012 11:19:13 AM Peter Bergner wrote: [snip]> That said, I'm curious about the extent of LLVM's support for PPC. > How robust is it? Does it support generating both 32-bit and 64-bit > binaries? >I use clang/LLVM to generate code for both ppc and ppc64. The support seems pretty robust so far: http://ellcc.org -Rich
On Sat, 28 Apr 2012 11:19:13 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote:> On Fri, 2012-04-27 at 20:30 -0500, Hal Finkel wrote: > > Thanks! Do you happen to know where this needs to be changed in > > clang or LLVM. The code that actually interprets the constraints, > > generically, is in CodeGen/SelectionDAG/TargetLowering.cpp, is clang > > relying on that code, or is there some frontend code in clang itself > > that is failing to initially interpret the string? If it is the > > code in TargetLowering, then I don't see any support there for '*' > > or '#'. > > Heh, I'm afraid I have no clue as to where clang needs to be changed. > I'm the team lead for IBM's Linux on POWER GCC development team, so > I can help you with questions about PPC hardware, PPC ABIs and why > GCC does things the way it does on PPC, but I'll not be of much > help with LLVM itself. I'm just a lurker here. :)That's great, thanks!> > That said, I'm curious about the extent of LLVM's support for PPC. > How robust is it? Does it support generating both 32-bit and 64-bit > binaries?LLVM supports generating both 32 bit and 64 binaries. I have used LLVM/clang to compile large and important codes on our Blue Gene supercomputers (and their POWER frontend nodes), including some that use the Boost C++ libraries; these codes run well and the performance is often quite reasonable. I've recently added processor itineraries for both the 440/450 and A2 embedded cores, and the code generation for these cores is now really quite good. There are some deficiencies, here are some that come to mind: - Support for the 128-bit double-double format used for long doubles on Linux (and AIX) is currently broken [I am actively working on fixing this]. - There is no support for generating position-independent code on PPC32. (PIC on PPC64 now works well). Nevertheless, I have sometimes run into linking errors when compiling shared libraries with C++ on PPC64. - There is no support for TLS. - Support for inline asm needs improvement (it often works, but sometimes I've run across unsupported constructs [as in this thread]). - The lowering code that generates the update forms of the load and store instructions is currently is buggy (and is disabled by default) [small test cases work, but enabling this on the test suite induces runtime failures]. This is currently my top priority for performance fixes (I am not sure how important it is on POWER, but on the embedded cores in makes a big difference) - There is currently no support for generating loops using control-registers for branch and increment (I am not sure if this matters on POWER, but it does make some difference for small trip-count loops on the embedded cores). - Register reservations can use some improvement. We currently need to reserve an additional register to handle the corner case where a condition register need to be spilled into a large stack frame (one register to compute the address, and a second one into which to transfer the condition register's contents). I'd like to improve this at some point. So if you stick to static linking and don't use TLS or long doubles, then it actually works quite well. Dynamic linking on PPC64 works most of the time. I've tried to keep the PPC 970 hazard detector in working order, but I've never really done much of a performance study on the non-embedded cores. Assistance with any of this would, of course, be greatly appreciated.> > I'll note that although I work on GCC, I have no problems seeing LLVM > supporting PPC. The more the merrier.Good! :) -Hal> > Peter > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Sat, Apr 28, 2012 at 11:19:13AM -0500, Peter Bergner wrote:> On Fri, 2012-04-27 at 20:30 -0500, Hal Finkel wrote: > > Thanks! Do you happen to know where this needs to be changed in clang > > or LLVM. The code that actually interprets the constraints, > > generically, is in CodeGen/SelectionDAG/TargetLowering.cpp, is clang > > relying on that code, or is there some frontend code in clang itself > > that is failing to initially interpret the string? If it is the code in > > TargetLowering, then I don't see any support there for '*' or '#'. > > Heh, I'm afraid I have no clue as to where clang needs to be changed. > I'm the team lead for IBM's Linux on POWER GCC development team, so > I can help you with questions about PPC hardware, PPC ABIs and why > GCC does things the way it does on PPC, but I'll not be of much > help with LLVM itself. I'm just a lurker here. :) > > That said, I'm curious about the extent of LLVM's support for PPC. > How robust is it? Does it support generating both 32-bit and 64-bit > binaries?Just two random points, we can compile and boot FreeBSD kernel and I was able to selfhost statically compiled clang/llvm. Beside missing PIC support and not saving FP args when CR bit 6 is not set there's nothing (famous last words) preventing FreeBSD from using clang as its default compiler on PPC. roman