llc generated assembly does not work with gcc 3.4.4

Hi,

I've generated a .bc file for a simple program using the clang front
end, the human readable output of llvm-dis looks good.
Running llc on the bc file generates an assembly file (.s using either
att or intel syntax).
Now, when I try to generate an executable with gcc (3.4.4 cygwin) I get
lot's of errors:

$ gcc t.S
t.S: Assembler messages:
t.S:4: Error: no such instruction: `align 16'
t.S:6: Error: invalid character '@' in mnemonic
t.S:7: Error: no such instruction: `bb'
t.S:20: Error: invalid character '@' in mnemonic
t.S:22: Error: no such instruction: `db "hello world\n\000"'

here is the assembly file (t.s):

    .text
    ALIGN 16
    .globl _main
_main: ; @main
; BB#0: ; %entry
    subl $20, %esp
    movl 24(%esp), %eax
    movl $0, 16(%esp)
    movl $($_.str), (%esp)
    movl %eax, 12(%esp)
    movl 28(%esp), %eax
    movl %eax, 8(%esp)
    call _printf
    movl 16(%esp), %eax
    addl $20, %esp
    ret
    .data
                                                            ; @.str
$_.str:
    db "hello world\n\000"

Aparently, gcc doesn't recognize ; as comments nor can it handle the db
directive.
How can I generate assembly that is accepted by gcc ??

Thx!

Alex

Hi,

I've generated a .bc file for a simple program using the clang front
end, the human readable output of llvm-dis looks good.
Running llc on the bc file generates an assembly file (.s using either
att or intel syntax).
Now, when I try to generate an executable with gcc (3.4.4 cygwin) I get
lot's of errors:

What commands are you passing to llc? Also, please attach the .ll file you're using.

-Chris

The ll file:

; ModuleID = 't.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i686-pc-win32"

@.str = private constant [13 x i8] c"hello world\0A\00" ; <[13 x i8]*>
[#uses=1]

define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
  %retval = alloca i32 ; <i32*> [#uses=2]
  %argc.addr = alloca i32 ; <i32*> [#uses=1]
  %argv.addr = alloca i8** ; <i8***> [#uses=1]
  store i32 0, i32* %retval
  store i32 %argc, i32* %argc.addr
  store i8** %argv, i8*** %argv.addr
  %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([13 x
i8]* @.str, i32 0, i32 0)) ; <i32> [#uses=0]
  %0 = load i32* %retval ; <i32> [#uses=1]
  ret i32 %0
}

declare i32 @printf(i8*, ...)

the llc command line is simply: llc t.bc (where t.bc is the file used
to generate the ll file shown, of course)

llc --version gives:

Low Level Virtual Machine (http://llvm.org/):
  LLVM (win32 vc8.0) version 2.600000e+000
  DEBUG build.
  Built Dec 3 2009 (01:18:42).

  Registered Targets:
    amdil - ATI graphics cards
    x86 - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

I've read in the docu (which appears to be somewhat out of date) that
one cannot generate binaries on win32 systems.
The thing I don't understand is why I cannot generate assembly that is
compatible with gcc (albait the cygwin version of gcc, but
certainly cygwin gcc reads the same mnemonics as the unix version??).
I've tryed several llc switches to produce compatible output but failed.

Alex

Chris Lattner schrieb:

Anton,

This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for mingw or cygwin. Does it make sense to remove the "Windows" target and have "i686-pc-win32" just be a synonym for mingw?

-Chris

Hi, Chris

This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for mingw or cygwin. Does it make sense to remove the "Windows" target and have "i686-pc-win32" just be a synonym for mingw?

This is ok for me. I think we need to go further and somehow indicate
that intel asmprinter will never be able generate code which, in
general, can be assembled.

Well, can I enforce gcc compatible output somehow? I tried playing with
the llc flags which didn't help.
A possible subtarget for windows might be masm,
the msvc compiler and the like.

Alex

Chris Lattner schrieb:

Well, can I enforce gcc compatible output somehow?

llc -x86-asm-syntax=att

Hi,

I tried that before, it produces

    .text
    ALIGN 16
    .globl _main
_main: ; @main
; BB#0: ; %entry
    subl $20, %esp
    movl $0, 16(%esp)
    movl 24(%esp), %eax
    movl %eax, 12(%esp)
    movl 28(%esp), %eax
    movl %eax, 8(%esp)
    movl $($_.str), (%esp)
    call _printf
    movl 16(%esp), %eax
    addl $20, %esp
    ret
    .data
                                                            ; @.str
$_.str:
    db "hello world\n\000"

which is not digested by gcc.

Alex

Anton Korobeynikov schrieb:

Hi,

I tried that before, it produces

Anton, the issue here is the 'isWindows' X86 sub-target. Should it just use the MCAsmInfo values as MingW?

-Chris

Hi, Chris

Anton, the issue here is the 'isWindows' X86 sub-target. Should it just use
the MCAsmInfo values as MingW?

Yes, it should. This was fixed in r96165

Great, thanks!