[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):

 heres the result of  {{{ ./Setup build -v }}}

 {{{  ./Setup build -v

 executable 'test'creating dist/build
 creating dist/build/autogen
 Building test-0.1.0.0...
 Preprocessing executable 'test' for test-0.1.0.0...
 Building executable test...
 creating dist/build/test
 creating dist/build/test/test-tmp
 '/usr/local/bin/ghc' '--make' '-no-link' '-fbuilding-cabal-package' '-O'
 '-static' '-odir' 'dist/build/test/test-tmp' '-hidir' 'dist/build/test
 /test-tmp' '-stubdir' 'dist/build/test/test-tmp' '-i' '-idist/build/test
 /test-tmp' '-isrc' '-idist/build/autogen' '-Idist/build/autogen'
 '-Idist/build/test/test-tmp' '-optP-include'
 '-optPdist/build/autogen/cabal_macros.h' '-hide-all-packages' '-package-
 db' 'dist/package.conf.inplace' '-package-id'
 'base-4.6.0.1-2514ecbfe6573e639515d3e91d6e1f29' '-package-id'
 'vector-0.10.0.1-04d4a4538e7c444d2821bb98877cda5f' '-XHaskell2010'
 'src/main.hs'
 Building C Sources...
 creating dist/build/test/test-tmp
 '/usr/local/bin/ghc' '-c' '-static' '-odir' 'dist/build/test/test-tmp'
 '-Idist/build/test/test-tmp' '-optc-march=native' '-optc-O3' '-optc-O2'
 '-package-db' 'dist/package.conf.inplace' '-package-id'
 'base-4.6.0.1-2514ecbfe6573e639515d3e91d6e1f29' '-package-id'
 'vector-0.10.0.1-04d4a4538e7c444d2821bb98877cda5f' 'cbits/daft.c'

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46908_0/ghc46908_0.s:6:0:
     no such instruction: `vmovupd (%rdi), %xmm0'

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46908_0/ghc46908_0.s:7:0:
     no such instruction: `vaddpd %xmm0, %xmm0,%xmm0'

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46908_0/ghc46908_0.s:8:0:
     no such instruction: `vmovupd %xmm0, (%rsi)'

 }}}

 heres my attempt at doing it as you suggest

 {{{carter code/test » '/usr/local/bin/ghc' '-c' '-static' '-odir'
 'dist/build/test/test-tmp' '-Idist/build/test/test-tmp' '-optc-
 march=native' '-opta-march=native' '-optc-O3' '-optc-O2' '-package-db'
 'dist/package.conf.inplace' '-package-id'
 'base-4.6.0.1-2514ecbfe6573e639515d3e91d6e1f29' '-package-id'
 'vector-0.10.0.1-04d4a4538e7c444d2821bb98877cda5f' 'cbits/daft.c' -opta-
 march=native

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46918_0/ghc46918_0.s:6:0:
     no such instruction: `vmovupd (%rdi), %xmm0'

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46918_0/ghc46918_0.s:7:0:
     no such instruction: `vaddpd %xmm0, %xmm0,%xmm0'

 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc46918_0/ghc46918_0.s:8:0:
     no such instruction: `vmovupd %xmm0, (%rsi)'

 }}}

 Let me repeat the problem: the apple assembler is OLD, and UNMAINTAINED.
 It is gas from ~ gcc-4.2 or slightly earlier days. There is no alternative
 "as" on mac, though gcc and clang sortah provide an assembler pass that
 doesn't seem to be usable as a full {{{as}}} substitute (or at least i've
 failed to figure out how to make that work). Thus, the only solution that
 is *robust* is to directly generate the object code from the C code or
 something similar.

 '''additionally ''', to restate nathan howell's remark, this is
 problematical even if the end user user isn't explicitly using AVX
 intrinsics, because gcc/clang will at the very least use the AVX
 instructions for scalar arithmetic on hardware that supports it (and thats
 even ignoring auto-vectorization). Likewise, when the assembly step isn't
 needed / useful, such as when (as in this code) i might be telling ghc
 -fllvm ( i don't have that in the example cabal, but would simple by
 adding a {{{ ghc-options: -fllvm }}} entry in the cabal after all) and
 theres definitely no reason to have the .s step in that case.

 does that help?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7922#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler