[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver

[GHC]

#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