[cfe-dev] [LLVMdev] Odd PPC inline asm constraint
hfinkel at anl.gov
Sat Apr 28 11:46:02 PDT 2012
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
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
- 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
- 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
- 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
> I'll note that although I work on GCC, I have no problems seeing LLVM
> supporting PPC. The more the merrier.
Leadership Computing Facility
Argonne National Laboratory
More information about the cfe-dev