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

[Peter Bergner]

On Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote:
> > >  - 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.

PPC64 is PIC by nature.  As for the linking issue, possibly you blew
the TOC with too many entries?  It used to be even with GCC, we could
not compile doxygen (with or without -mminimal-toc) without filling
up the TOC and hitting the TOC overflow linker error. T fix those types
of problems, we recently added two more code models to GCC/binutils, so
we're no longer limited to 16-bit TOC offsets.  We now how -mcmodel=medium
(32-bit TOC offsets) and -mcmodel=large (64-bit TOC offsets), with
-mcmodel=medium being the new GCC default (on PPC64).  The old TOC code
is now called -mcmodel=small.




> > >  - 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).

It helps on our server class hardware too, so we do make use of it.


> > >  - 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.

Reserve as in you don't allow anything to be allocated to it just in
the uncommon case you have to spill a condition reg to a stack slot you
cannot write to with a 16-bit offset?  Speaking as a person who has
implemented register allocators, that is bad!



> Roman pointed out to me that I misspoke. LLVM only generates PIC on
> Darwin, not for ELF. What does work on PPC64 is dynamic linking
> (meaning that it will correctly put nop after the calls so that the
> linker can do its thing). To support dynamic linking on PPC32 we'd need
> to explicitly add other things (stubs?) and that is not implemented.

If by stubs you mean PLT call stubs, those are created by the linker
for both PPC and PPC64 binaries.

I'm not sure what distro you're running on, but you may be hitting
the new 32-bit secure-plt implementation all new distros are using.
The old 32-bit PLT code used to  generatie a branch/return to the GOT
and the updated LR value was used to gain addressability to the GOT.
The problem is that the GOT is in the date section, so for that to
work, the data section of your program had to be marked executable.
With -msecure-plt (the new default for all new distros), that is
no longer the case.  Maybe the non secure-plt code isn't playing
well with the system crt*.o files and libs?

Are there build directions for building LLVM for ppc/ppc64?
I thought I had read that clang didn't work for ppc/ppc64 and that
you had to use llvm-gcc thingy.  Is that not the case anymore?

Peter