On Tue, 01 May 2012 17:23:07 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote:> On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > > LLVM/clang now will build in the normal way (./configure; make > > install) on PPC (you'll need at least the 3.1 release candidate (or > > trunk)). I generally build on my PPC64 hosts with: > > make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 > > EXTRA_OPTIONS=-mminimal-toc > > Ok, it built fine, but what is the llvm equivalent of gcc's -m32 -m64? > Google doesn't seem to be much help, nor is the clang --help output.Noted, we should fix that as well. By default it should build for whatever the current host is (no special flags required). To specifically build for something else, use: -ccc-host-triple powerpc64-unknown-linux-gnu or -ccc-host-triple powerpc-unknown-linux-gnu The other secret is to try: --help-hidden (for all of the driver options) and also: -cc1 -help (this shows all of the compiler options; many of these [especially the ones that look like gcc options] are passed through to the compiler [for the others, you'd need to use -Xclang <option>]. -Hal> > Peter > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Tue, 2012-05-01 at 17:47 -0500, Hal Finkel wrote:> By default it should build for > whatever the current host is (no special flags required). To > specifically build for something else, use: > -ccc-host-triple powerpc64-unknown-linux-gnu > or > -ccc-host-triple powerpc-unknown-linux-gnuSo LLVM isn't biarch capable? Meaning one LLVM compiler cannot generate both 32-bit and 64-bit binaries? Peter
On Tue, 01 May 2012 19:58:23 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote:> On Tue, 2012-05-01 at 17:47 -0500, Hal Finkel wrote: > > By default it should build for > > whatever the current host is (no special flags required). To > > specifically build for something else, use: > > -ccc-host-triple powerpc64-unknown-linux-gnu > > or > > -ccc-host-triple powerpc-unknown-linux-gnu > > So LLVM isn't biarch capable? Meaning one LLVM compiler cannot > generate both 32-bit and 64-bit binaries?It can, you can provide those on the clang command line. -Hal> > Peter > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Tue, 2012-05-01 at 19:58 -0500, Peter Bergner wrote:> On Tue, 2012-05-01 at 17:47 -0500, Hal Finkel wrote: > > By default it should build for > > whatever the current host is (no special flags required). To > > specifically build for something else, use: > > -ccc-host-triple powerpc64-unknown-linux-gnu > > or > > -ccc-host-triple powerpc-unknown-linux-gnu > > So LLVM isn't biarch capable? Meaning one LLVM compiler cannot > generate both 32-bit and 64-bit binaries?Sorry for replying to my own message, but... Oh, -ccc-host-triple is a compiler option and not a configure option. That does work, though it seems I have to link with gcc, since llvm still wants to link against the 64-bit crt*.o and libs. Maybe it is easier to just have two separate builds. That said, my simple dynamically linked hello world executed fine (ie, it was able to call into libc.so just fine), as well as an old C version of the SPEC97 tomcatv benchmark I have laying around. So it seems both 32-bit and 64-bit can call into shared libs. Not to say I haven't seen some code gen warts (using -O3). :)>From hello.s:main: mflr 0 stw 31, -4(1) stw 0, 4(1) stwu 1, -16(1) lis 3, .Lstr at ha mr 31, 1 la 3, .Lstr at l(3) bl puts li 3, 0 addi 1, 1, 16 lwz 0, 4(1) lwz 31, -4(1) mtlr 0 blr By the strict letter of the 32-bit ABI, the save and restore of r31 at a negative offset of r1 is verboten. The ABI states the the stack space below the stack pointer is declared as volatile. I actually debugged a similar problem way back in my Blue Gene/L days, where gcc had a bug and was doing the same thing. We ended up taking a signal between the restore of the stack pointer and the restore of the nonvolatile reg and the BGL compute node kernel trashed the stack below the stack pointer. The second wart is the dead copy to r31...which leads to the unnecessary save and restore of r31. For tomcatv, we have to basically save/restore the entire set of non-volatile integer and fp registers. Looking at how llvm does that shows: ... lis 3, 56 ori 3, 3, 57680 stwx 16, 31, 3 lis 3, 56 ori 3, 3, 57684 stwx 17, 31, 3 lis 3, 56 ori 3, 3, 57688 stwx 18, 31, 3 lis 3, 56 ori 3, 3, 57692 stwx 19, 31, 3 lis 3, 56 ori 3, 3, 57696 stwx 20, 31, 3 lis 3, 56 ori 3, 3, 57700 stwx 21, 31, 3 [repeated over and over and ...] Kind of ugly! :) GCC on the other hand stashes away the old value of the stack pointer and then uses small negative offsets (legal at this point since we've already decremented the stack pointer) from that for all of its saves/restores: ... lis 0,0xffc7 mr 12,1 ori 0,0,7728 stwux 1,1,0 mflr 0 stw 0,4(12) stfd 14,-144(12) stfd 15,-136(12) stfd 16,-128(12) stfd 17,-120(12) stfd 18,-112(12) ... For things that don't work, do you have a small example program that shows what's wrong? Peter
On Tue, May 01, 2012 at 05:47:15PM -0500, Hal Finkel wrote:> On Tue, 01 May 2012 17:23:07 -0500 > Peter Bergner <bergner at vnet.ibm.com> wrote: > > > On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > > > LLVM/clang now will build in the normal way (./configure; make > > > install) on PPC (you'll need at least the 3.1 release candidate (or > > > trunk)). I generally build on my PPC64 hosts with: > > > make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 > > > EXTRA_OPTIONS=-mminimal-toc > > > > Ok, it built fine, but what is the llvm equivalent of gcc's -m32 -m64? > > Google doesn't seem to be much help, nor is the clang --help output. > > Noted, we should fix that as well. By default it should build forfwiw, on FreeBSD -m32 works just fine with clang. Take a look at r132634/r132635. You can get some inspiration for the linux toolchain. roman
Seemingly Similar Threads
- [LLVMdev] [cfe-dev] Odd PPC inline asm constraint
- [LLVMdev] [cfe-dev] Odd PPC inline asm constraint
- [LLVMdev] [cfe-dev] Odd PPC inline asm constraint
- flac-1.1.1 completely broken on linux/ppc and on macosx if built with the standard toolchain (not xcode)
- [LLVMdev] Testing LLVM on OS X