Proper arguments for -march?

llc -march=x86 tempfileB.bc yields:
llc: for the -march option: : Cannot find option named 'x86'!

Windows build using Visual Studio 2008 Express with CMake.

clang and other tools seem to also complain about the format of -march, but other command line arguments seem to be working. Tools, clang llvm-as, opt, etc., "seem" to be working.

Incidently, the bytecode file was built using this command:
clang test1.c -emit-llvm > tempfileA
llvm-as < tempfileA > tempfileB.bc

Contents of tempfileA is:
; ModuleID = 'test1.c'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-win32"

define i32 @main(...) nounwind {
entry:
    %retval = alloca i32 ; <i32*> [#uses=1]
    %i = alloca i32, align 4 ; <i32*> [#uses=5]
    %j = alloca i32, align 4 ; <i32*> [#uses=1]
    store i32 0, i32* %i
    br label %for.cond

for.cond: ; preds = %for.inc, %entry
    %tmp = load i32* %i ; <i32> [#uses=1]
    %cmp = icmp slt i32 %tmp, 10 ; <i1> [#uses=1]
    br i1 %cmp, label %for.body, label %for.end

for.body: ; preds = %for.cond
    %tmp1 = load i32* %i ; <i32> [#uses=1]
    %add = add i32 %tmp1, 5 ; <i32> [#uses=1]
    store i32 %add, i32* %j
    br label %for.inc

for.inc: ; preds = %for.body
    %tmp2 = load i32* %i ; <i32> [#uses=1]
    %inc = add i32 %tmp2, 1 ; <i32> [#uses=1]
    store i32 %inc, i32* %i
    br label %for.cond

for.end: ; preds = %for.cond
    br label %return

return: ; preds = %for.end
    %0 = load i32* %retval ; <i32> [#uses=1]
    ret i32 %0
}

Hello,

Currently the CMake project (on Windows) doesn't cause any backends to
be included in llc (due to the stripping of unreferenced global
objects).

I posted a patch a couple days ago if you want to try it, or Oscar
intends to improve/fix/reimplement and commit shortly.

scott

CMake was set as follows:
LLVM_TARGETS_TO_BUILD CBackend;PIC16;X86

Here's what llc returned:

OVERVIEW: llvm system compiler

USAGE: llc [options] <input bitcode>

OPTIONS:
  -asm-verbose - Add comments to directives.
  -code-model - Choose code model
    =default - Target default code model
    =small - Small code model
    =kernel - Kernel code model
    =medium - Medium code model
    =large - Large code model
  -disable-excess-fp-precision - Disable optimizations that may increase FP precision
  -disable-fp-elim - Disable frame pointer elimination optimization
  -disable-post-RA-scheduler - Disable scheduling after register allocation
  -enable-correct-eh-support - Make the -lowerinvoke pass insert expensive, but correct, EH code
  -enable-eh - Emit DWARF exception handling (default if target supports)
  -enable-finite-only-fp-math - Enable optimizations that assumes non- NaNs / +-Infs
  -enable-unsafe-fp-math - Enable optimizations that may decrease FP precision
  -f - Overwrite output files
  -fast - Generate code quickly, potentially sacrificing code quality
  -filetype - Choose a file type (not all types are supported by all targets):
    =asm - Emit an assembly ('.s') file
    =obj - Emit a native object ('.o') file [experimental]
    =dynlib - Emit a native dynamic library ('.so') file [experimental]
  -help - Display available options (--help-hidden for more)
  -join-liveintervals - Coalesce copies (default=true)
  -limit-float-precision=<uint> - Generate low-precision inline sequences for some float libcalls
  -load=<pluginfilename> - Load the specified plugin
  -march - Architecture to generate code for:
  -mattr=<a1,+a2,-a3,...> - Target specific attributes (-mattr=help for details)
  -mcpu=<cpu-name> - Target a specific cpu type (-mcpu=help for details)
  -mtriple=<string> - Override target triple for module
  -nozero-initialized-in-bss - Don't place zero-initialized symbols into bss section
  -o=<filename> - Output filename
  -pre-RA-sched - Instruction schedulers available (before register allocation):
    =default - Best scheduler for the target
    =fast - Fast suboptimal list scheduling
    =list-td - Top-down list scheduler
    =list-burr - Bottom-up register reduction list scheduling
    =list-tdrr - Top-down register reduction list scheduling
  -print-machineinstrs - Print generated machine code
  -realign-stack - Realign stack if needed
  -regalloc - Register allocator to use: (default = linearscan)
    =simple - simple register allocator
    =local - local register allocator
    =bigblock - Big-block register allocator
    =linearscan - linear scan register allocator
    =pbqp - PBQP register allocator
  -relocation-model - Choose relocation model
    =default - Target default relocation model
    =static - Non-relocatable code
    =pic - Fully relocatable, position independent code
    =dynamic-no-pic - Relocatable external references, non-relocatable code
  -schedule-livein-copies - Schedule copies of livein registers
  -soft-float - Generate software floating point library calls
  -spiller - Spiller to use: (default: local)
    =simple - simple spiller
    =local - local spiller
  -stack-alignment=<uint> - Override default stack alignment
  -stack-protector-buffer-size=<uint> - The lower bound for a buffer to be considered for stack smashing protection.
  -stats - Enable statistics output from program
  -tailcallopt - Turn on tail call optimization.
  -time-passes - Time each pass, printing elapsed time for each on exit
  -unwind-tables - Generate unwinding tables for all functions
  -verify-dom-info - Verify dominator info (time consuming)
  -version - Display the version of this program

Anton Korobeynikov wrote:

Hi,
I assume that the following means the backends are not registred:

sequences for some float libcalls
  -load=<pluginfilename> - Load the specified plugin
  -march - Architecture to generate code for:
  -mattr=<a1,+a2,-a3,...> - Target specific attributes (-mattr=help for details)

When does the registration occur? During the build? If so there's a problem with CMake for Visual Studio.
Or, is it something I need to do manually after building?

Thanks for any help. I'm too new at this.

Henry

Anton Korobeynikov wrote: