[cfe-dev] [LLVMdev] Odd PPC inline asm constraint

[Hal Finkel]

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