clang builds on Sparc/Linux!

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

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.

SparcAsmPrinter.cpp.patch (412 Bytes)

SparcRegisterInfo.cpp.patch (348 Bytes)

Hi Kelly,

Sorry for the delay, I'm way behind in email :frowning:

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

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.

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:

-Chris

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

Thanks,
K.Wilson