#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #7904 | ---------------------------------+------------------------------------------ Comment(by carter): consider the following program, which i'll call {{{ daft.c }}} {{{ #include <immintrin.h> __m128d myVAdd(__m128d a, __m128d b){ return _mm_add_pd ( a, b); }}} before i build it lets assume you've installed llvm-3.2 and the associated build of clang. lets check what the host architecture llvm/ clang sees on my machine {{{ llc --version LLVM (http://llvm.org/): LLVM version 3.4svn Optimized build with assertions. Built May 17 2013 (14:27:28). Default target: x86_64-apple-darwin12.3.0 Host CPU: corei7-avx }}} ok, so -march=native should pick out avx versions of instructions when i run {{{ clang -c -S daft.c -march=native}}} i get the following assembly code in {{{ daft.s }}} {{{ .section __TEXT,__text,regular,pure_instructions .globl _myVAdd .align 4, 0x90 _myVAdd: ## @myVAdd .cfi_startproc ## BB#0: ## %entry pushq %rbp Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp4: .cfi_def_cfa_register %rbp vmovapd %xmm0, -48(%rbp) vmovapd %xmm1, -64(%rbp) vmovapd -48(%rbp), %xmm0 vmovapd %xmm0, -16(%rbp) vmovapd %xmm1, -32(%rbp) vmovapd -16(%rbp), %xmm0 vaddpd -32(%rbp), %xmm0, %xmm0 popq %rbp ret .cfi_endproc .subsections_via_symbols }}} if i then run {{as}} on this file, {{{ as daft.s }} i get {{{ daft.s:5:Unknown pseudo-op: .cfi_startproc daft.s:9:Unknown pseudo-op: .cfi_def_cfa_offset daft.s:9:Rest of line ignored. 1st junk character valued 49 (1). daft.s:11:Unknown pseudo-op: .cfi_offset daft.s:11:Rest of line ignored. 1st junk character valued 37 (%). daft.s:14:Unknown pseudo-op: .cfi_def_cfa_register daft.s:14:Rest of line ignored. 1st junk character valued 37 (%). daft.s:15:no such instruction: `vmovapd %xmm0, -48(%rbp)' daft.s:16:no such instruction: `vmovapd %xmm1, -64(%rbp)' daft.s:17:no such instruction: `vmovapd -48(%rbp), %xmm0' daft.s:18:no such instruction: `vmovapd %xmm0, -16(%rbp)' daft.s:19:no such instruction: `vmovapd %xmm1, -32(%rbp)' daft.s:20:no such instruction: `vmovapd -16(%rbp), %xmm0' daft.s:21:no such instruction: `vaddpd -32(%rbp), %xmm0,%xmm0' daft.s:24:Unknown pseudo-op: .cfi_endproc }}} now if i instead do {{{ clang --march=native -c -S daft.c }}} i get a nice avx object code file, but thats not possible if ghc is acting as the driver because of the .s step. instead i need to do something like {{{ clang -c -S -march=native -msse4.2}}} (which seems per se more fragile than saying native) if i want to make sure that compilation succeeds. is this a satisfactory explication -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7922#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler