Hello everyone, I am running an Enterprise 250 with Dual UltraSparc II's and 2 Gb ram running Aurora Sparc Linux 2.0 (2.6.13 kernel for Aurora is based on Fedora Core 3). GCC version 3.4.2. I built llvm-2.0 (the svn version) by just typing "./configure;make". I then downloaded clang from the svn repository (revision 40382) and changed to it's directory under .../llvm/tools/clang. I did a "make" without incident for clang, as well. Woohoo. I tried a few examples and everything seemed to work fine, as far as llvm, some simple clang functionality and the JIT examples go. Then I ran this contrived example through clang and llvm: int x; int func1 (int g) { return g; } int main() { printf("Hello World %d times\n", func1(5)); } with this command: clang ./ex1.c -emit-llvm | llvm-as | opt -std-compile-opts | llc -march=sparc > ex1.S This worked fine and the code gen looked fine, except for two things: .text .align 16 .globl func1 .type func1, #function func1: save -96, %o6, %o6<---------------change restore %g0, %g0, %g0 retl nop .align 16 .globl main .type main, #function main: save -96, %o6, %o6<---------------change sethi %hi(.str), %l0 add %l0, %lo(.str), %o0 or %g0, 5, %o1 call printf nop !IMPLICIT_DEF %i0 restore %g0, %g0, %g0 retl nop .globl x .bss <-------------------------------------remove .align 4 .type x,#object .size x,4 x: .skip 4 .data .align 1 .type .str,#object .size .str,22 .str: .asciz "Hello World %d times\n" The two problems with this output. "save -96, %o6, %o6" should read "save %o6, -96, %o6" at both function entry points, and the ".bss" section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK THIS AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, though I may be the only one running this pair ;) There are a couple patches attached to fix things for Sparc/Linux/gcc. Let me know if anyone wants anymore information. I will do some more testing and let you know how it goes. Thanks, Kelly Wilson P.S. Chris already replied on another list to this post. On Tue, 24 Jul 2007, Chris Lattner wrote:>> The two problems with this output. "save -96, %o6, %o6" should read >> "save %o6, -96, %o6" at both function entry points, and the ".bss" >> section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK >> THIS >> AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, >> though I may be the only one running this pair ;)>Very nice! I'm not sure how the arguments to save got transposed, it >must be a regression somewhere along the way. We don't have too many >people testing sparc :)This isn't actually an error of transposition for Sparc/SunOS when using the "cc" compiler. This "save -96, %o6, %o6" (and the .bss section identifier) work when using SunOS "cc" but not "gcc" under SunOS. My patches will assume that everyone is using "cc" under SunOS...because we can't check in llc whether someone will use "cc" or "gcc" to assemble and link in the future ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: SparcAsmPrinter.cpp.patch Type: text/x-patch Size: 400 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070724/662fae20/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: SparcRegisterInfo.cpp.patch Type: text/x-patch Size: 339 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070724/662fae20/attachment-0001.bin>
On Tue, 24 Jul 2007 wilsonk at cpsc.ucalgary.ca wrote: Hi Kelly, Sorry for the delay, I'm way behind in email :(> I built llvm-2.0 (the svn version) by just typing "./configure;make". I > then downloaded clang from the svn repository (revision 40382) and changed > to it's directory under .../llvm/tools/clang. I did a "make" without > incident for clang, as well. Woohoo.Nice!> This worked fine and the code gen looked fine, except for two things: > func1: > save -96, %o6, %o6<---------------change > main: > save -96, %o6, %o6<---------------change> .globl x > .bss <-------------------------------------remove > .align 4> The two problems with this output. "save -96, %o6, %o6" should read > "save %o6, -96, %o6" at both function entry points, and the ".bss" > section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK THIS > AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, > though I may be the only one running this pair ;)Very nice! I assume this is because you're using the sun assembler instead of the GNU assembler. Do you know if the reordered save operands work with the GNU assembler? -Chris> There are a couple patches attached to fix things for Sparc/Linux/gcc. > > Let me know if anyone wants anymore information. I will do some more > testing and let you know how it goes. > > Thanks, > Kelly Wilson > > P.S. Chris already replied on another list to this post. > > On Tue, 24 Jul 2007, Chris Lattner wrote: > >>> The two problems with this output. "save -96, %o6, %o6" should read >>> "save %o6, -96, %o6" at both function entry points, and the ".bss" >>> section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK >>> THIS >>> AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, >>> though I may be the only one running this pair ;) > >> Very nice! I'm not sure how the arguments to save got transposed, it >> must be a regression somewhere along the way. We don't have too many >> people testing sparc :) > > > This isn't actually an error of transposition for Sparc/SunOS when using > the "cc" compiler. This "save -96, %o6, %o6" (and the .bss section > identifier) work when using SunOS "cc" but not "gcc" under SunOS. > > My patches will assume that everyone is using "cc" under SunOS...because > we can't check in llc whether someone will use "cc" or "gcc" to assemble > and link in the future ;) > > > > >-Chris -- http://nondot.org/sabre/ http://llvm.org/
Hey Chris, At the end of your previous email below you have asked whether the reordered save operands work with GNU as. The order for save operands in Sun's Assembler is what regularly comes out the back of your Sparc backend ala: save -96, %o6, %o6 And Sun's Assembler understands the .bss section identifier. So, if I just use llvm to produce a .S file and then use Sun's 'cc' to assemble/link , then everything is good. I only had the problems with reordered opeands because I am used to using gcc all the time ;) The order for GNU Assembler is: save %o6, -96, %o6 with no .bss section identifier. The patches that I submitted just assume that the user will use Sun's 'cc' for linking and assembling (unless the user wants to define "linux" when producing the .S file with llvm....but I would just suggest using 'cc' ;) Thanks, K.Wilson On Mon, 6 Aug 2007, Chris Lattner wrote:> On Tue, 24 Jul 2007 wilsonk at cpsc.ucalgary.ca wrote: > > Hi Kelly, > > Sorry for the delay, I'm way behind in email :( > >> I built llvm-2.0 (the svn version) by just typing "./configure;make". I >> then downloaded clang from the svn repository (revision 40382) and changed >> to it's directory under .../llvm/tools/clang. I did a "make" without >> incident for clang, as well. Woohoo. > > Nice! > >> This worked fine and the code gen looked fine, except for two things: >> func1: >> main: >> save -96, %o6, %o6<---------------change > >> .globl x >> .bss <-------------------------------------remove >> .align 4 > >> The two problems with this output. "save -96, %o6, %o6" should read >> "save %o6, -96, %o6" at both function entry points, and the ".bss" >> section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK THIS >> AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, >> though I may be the only one running this pair ;) > > Very nice! I assume this is because you're using the sun assembler > instead of the GNU assembler. Do you know if the reordered save operands > work with the GNU assembler? > > -Chris