clang builds on Sparc/Linux!

Hello everyone,

I am not sure if this is the correct list for this, but I think so,
because llvm-gcc didn't build error-free on Sparc/Linux last time I
tried....but clang does!

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 (not the svn version but the download 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 :wink:

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. Maybe I should cross-post this to llvm-dev so that the Sparc
backend writers can see it? I also have a couple very small diff's to
fix these two problems in the Sparc backend...should I post them to
llvm-dev?

I am not sure if this is the correct list for this, but I think so,
because llvm-gcc didn't build error-free on Sparc/Linux last time I
tried....but clang does!

Cool! :slight_smile:

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 (not the svn version but the download 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. You probably got a bit lucky :). Usually clang SVN head will only work with LLVM SVN head.

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:

Ok

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 :wink:

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 :slight_smile:

P.S. Maybe I should cross-post this to llvm-dev so that the Sparc
backend writers can see it? I also have a couple very small diff's to
fix these two problems in the Sparc backend...should I post them to
llvm-dev?

Yes please. I'm actually the author/maintainer of the sparc backend, but llvm-dev is the right place to take care of these bugs. Thanks!

-Chris

Hey Chris,

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 :wink:

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 :slight_smile:

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 :wink:

Thanks,
Kelly Wilson

P.S. I will post patches to llvm-dev.