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