[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #7904 -----------------------------+---------------------------------------------- currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats. Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like {{{ gcc source.c -c }}} rather than {{{ gcc source.c -s -c }}} (these are not necessarily the right flags, but rather a strawman representation of the difference). on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef Likewise, when doing -fllvm compilation, the *.c-> *.s phase just slows down the compilation process period. I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes This is not -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => infoneeded * difficulty: => Unknown Comment: Can you give a small example demonstrating the problem with `-march=native` on OS X, please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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): note that while i have llvm 3.4 on my machine, the same steps should work with any vaguely recent gcc or clang on a late 2011 or newer mac (anything that has sandybridge or newer) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 igloo): But those commands aren't using ghc to compile it? How can I reproduce the problem using GHC? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 | ---------------------------------+------------------------------------------ Changes (by nathanhowell): * cc: nathanhowell@… (added) Comment: Two ways I can think of: adding AVX instrinsics/primops or using LLVM's autovectorizer. I think the LLVM backend should skip the assembler step when it can emit object files directly (llc -filetype=obj with LLVM 3.0+?) and no asm munging is required. Likewise for C or C++ files. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): i've added a minimal test case, the mini cabalized test case has cc- options containing -march=native. if you have a gcc in your path that is newer than the apple provided one, this will work I'll now attache a variant that uses a more involved process so you can use clang instead of having to build a newer gcc if you dont have one handy -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): hrmm... I can't seem to get ghc to use clang instead. But if you install a newer version of gcc than the apple provided 4.2 (such as 4.8) and make sure that ghc picks the first gcc in its path (and have that be eg gcc 4.8), you can replicate this test case. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 igloo): Hmm. If you run "./Setup build -v" then you should see Cabal running a command like {{{ /usr/bin/ghc [...] -optc-march=native [...] -c cbits/daft.c }}} I presume that that command fails, but that if you run {{{ /usr/bin/ghc [...] -optc-march=native -opta-march=native [...] -c cbits/daft.c }}} then compilation succeeds? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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 igloo): Can you attach the output of that `ghc` command with a `-v` flag appended, please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): {{{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 -v3 Glasgow Haskell Compiler, Version 7.6.2, stage 2 booted by GHC version 7.4.2 Using binary package database: /usr/local/lib/ghc-7.6.2/package.conf.d/package.cache Using binary package database: /Users/carter/.ghc/x86_64-darwin-7.6.2/package.conf.d/package.cache Using package config file: dist/package.conf.inplace hiding package hashable-1.1.2.5 to avoid conflict with later version hashable-1.2.0.5 hiding package unordered-containers-0.2.3.0 to avoid conflict with later version unordered-containers-0.2.3.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-bd1d393903577692a5ef2aa7027b71f6 wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-49dcb29a60dab14e03e6dd01e871a242 wired-in package base mapped to base-4.6.0.1-2514ecbfe6573e639515d3e91d6e1f29 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-0ad833f8876aca146ee7fa686b5bc01a wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static -static Created temporary directory: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0 *** C Compiler: 'gcc' '-m64' '-fno-stack-protector' '-m64' '-x' 'c' 'cbits/daft.c' '-o' '/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s' '-fno-common' '-U __PIC__' '-D__PIC__' '-Wimplicit' '-S' '-O' '-D__GLASGOW_HASKELL__=706' '-DTABLES_NEXT_TO_CODE' '-march=native' '-O3' '-O2' '-I' 'dist/build/test/test-tmp' '-I' '/Users/carter/Library/Haskell//lib/x86_64-osx- ghc-7.6.2/vector-0.10.0.1/include' '-I' '/Users/carter/Library/Haskell//lib/x86_64-osx- ghc-7.6.2/primitive-0.5.0.1/include' '-I' '/usr/local/lib/ghc-7.6.2/base-4.6.0.1/include' '-I' '/usr/local/lib/ghc-7.6.2/include' *** Assembler: 'gcc' '-m64' '-fno-stack-protector' '-m64' '-march=native' '-march=native' '-Idist/build/test/test-tmp' '-c' '/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s' '-o' 'dist/build/test/test-tmp/cbits/daft.o' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s:6:0: no such instruction: `vmovupd (%rdi), %xmm0' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s:7:0: no such instruction: `vaddpd %xmm0, %xmm0,%xmm0' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s:8:0: no such instruction: `vmovupd %xmm0, (%rsi)' *** Deleting temp files: Deleting: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0/ghc47284_0.s *** Deleting temp dirs: Deleting: /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc47284_0 }}} oddly, even though it says its using gcc to do the assembly in the verbose log, running dtrace via the instruments application confirms that its actually using the '''as ''' apple assembler. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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 | ---------------------------------+------------------------------------------ Changes (by igloo): * status: infoneeded => new Comment: Presumably we call gcc, and gcc calls as. Hmm. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): NOPE. '''gcc''' is not calling '''as''', GHC is. gcc 4.8 can assemble the simd avx code just fine on my mac, so unless we're telling gcc to use as, its ghc. {{{ carter code/test » cd cbits carter test/cbits » gcc daft.c -S -c carter test/cbits » gcc daft.s -c carter test/cbits » ls daft.c daft.o daft.s }}} I then disassembled the object file generated by the compiling of the assembly, and it had the avx instructions -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): I should also remark that passing "-pgma gcc" has the exact same behavior as not passing it. I'm still trying to understand the ghc driver modules, so i'm not sure whats actually happening here. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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 igloo): What about if you run: {{{ cd cbits gcc -m64 -fno-stack-protector -m64 -x c cbits/daft.c -fno-common -Wimplicit -S -march=native -O2 gcc -m64 -fno-stack-protector -m64 -march=native -c daft.s }}} ? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): huh, you're right. {{{ carter test/cbits » gcc -m64 -fno-stack-protector -m64 -x c daft.c -fno- common -Wimplicit -S -march=native -O2 127 ↵ carter test/cbits » gcc -m64 -fno-stack-protector -m64 -march=native -c daft.s daft.s:6:no such instruction: `vmovupd (%rdi), %xmm0' daft.s:7:no such instruction: `vaddpd %xmm0, %xmm0,%xmm0' daft.s:8:no such instruction: `vmovupd %xmm0, (%rsi)' }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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 igloo): Just to check, does it compile if you say {{{ gcc -m64 -fno-stack-protector -m64 -x c -c cbits/daft.c -fno-common -Wimplicit -march=native -O2 }}} ? (i.e. not going via `.s`) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): {{{ carter code/test » gcc -m64 -fno-stack-protector -m64 -x c -c cbits/daft.c -fno-common -Wimplicit -march=native -O2 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:6:no such instruction: `vmovupd (%rdi), %xmm0' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:7:no such instruction: `vaddpd %xmm0, %xmm0,%xmm0' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T//ccBZdtfA.s:8:no such instruction: `vmovupd %xmm0, (%rsi)' }}} funnily enough, i accidently ran it as cc (which is apparently an alias for the apple dev tools clang on my machine / all macs) instead of gcc before i pasted i correctly with gcc, and it worked fine that way. ie, the same invocation, with cc (apple dev tools clang) or clang (llvm 3.4) instead of gcc, works / generates object code. heres the .s generated generated when i invoke clang with those arguments plus a {{{ -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 (%rdi), %xmm0 vaddpd %xmm0, %xmm0, %xmm0 vmovapd %xmm0, (%rsi) popq %rbp ret .cfi_endproc .subsections_via_symbols }}} just for comparison heres the gcc .s output {{{ .text .align 4,0x90 .globl _myVAdd _myVAdd: LFB802: vmovupd (%rdi), %xmm0 vaddpd %xmm0, %xmm0, %xmm0 vmovupd %xmm0, (%rsi) ret LFE802: .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long 0 .byte 0x1 .ascii "zR\0" .byte 0x1 .byte 0x78 .byte 0x10 .byte 0x1 .byte 0x10 .byte 0xc .byte 0x7 .byte 0x8 .byte 0x90 .byte 0x1 .align 3 LECIE1: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .long LASFDE1-EH_frame1 .quad LFB802-. .set L$set$2,LFE802-LFB802 .quad L$set$2 .byte 0 .align 3 LEFDE1: .subsections_via_symbols }}} maybe gcc uses the system {{{as}}} and clang doesn't because it goes via the llvm backend. or maybe i'm just tired and I need to revisit how got get gcc to work here later. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): ok, looks like i've not been able to use gcc to generate AVX code period, it looks like I might be able to use gcc to generate .s and then use clang as the assembler, but there some oddities that make me worried that its not actually correct, but i'll look at it when i'm better rested -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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 igloo): So my hope is that if {{{ $compiler $flags -c foo.c }}} works, then so does {{{ $compiler $flags -S foo.c $compiler $flags -c foo.s }}} If that's so, then I think we can close this ticket. But I'm not sure whether you have a case where that's not so, and if you do, whether it still causes you problems? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new 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): {{{gcc -c -S foo.c ; clang -c foo.s }}} works, via gcc doesnt HOWEVER, if i add the following flags to the ghc options section of cabal: {{{ ghc-options: -fllvm -pgma clang -pgmc clang }}} the build still doesn't work! (same error as before) I '''can''' change the ghc settings file to have {{{clang}}} be the default c compiler and then the build succeeds {{{ carter code/test » cabal clean ; cabal configure ; cabal build cleaning... Resolving dependencies... Configuring test-0.1.0.0... Warning: The 'license-file' field refers to the file 'LICENSE' which does not exist. /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/81694.c:1:12: warning: control reaches end of non-void function [-Wreturn-type] int foo() {} ^ 1 warning generated. Building test-0.1.0.0... Preprocessing executable 'test' for test-0.1.0.0... [1 of 1] Compiling Main ( src/main.hs, dist/build/test/test- tmp/Main.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... Linking dist/build/test/test ... }}} This would not work if I had any haskell modules running the clang C preprocessor however. (if that issue isn't in the relevant clang tickets, I can spend some time making a small reproducible test case) but theres a number of issues still outstanding with using clang as the default c compiler, including the fact that with the default flags, clang errors out when used as the c preprocessor . So i'm not comfortable with this ticket being closed until at least thats sorted out. Likewise, as Nathan Howell pointed out, not providing the .c->.o variant 1. adds an extra step to build processes that have lots of c code (and doubly so on the llvm) 2. makes it possible to just provide -pgmc clang for the relevant code and have things work (and doesn't require the end user / library client to have clang as their c compiler in the ghc settings file, which isn't something normal ghc users should have to fiddle with ) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #7904 -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: I'm a little confused by some of the details in the history of this ticket, but I suspect that if the same compiler is used to compile to asm and then to object code then it will succeed (assuming that that compiler can compile the C at all). Even if there is some compiler, with certain flags, for which that isn't true, I'm confident that there is a set of pgmP, pgmc and pgma that will work. I don't think that the benefits of making this change would outweigh the disadvantages, so I'm closing the ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #7904 -------------------------------+-------------------------------------------- Changes (by carter): * status: closed => new * resolution: wontfix => Comment: no, with the ghc Settings file indicating gcc as the c compiler, i can't get the code sample to build using -pgma clang -pgmc clang and cc- options: -march=native (which are the only relevant flags for this problem as i understand it) Unless i'm missing a relevant flag, that seems to be a problem / bug. If you'd like me to open that up as another ticket as a bug rather than feature request, thats all well and good, but please indicate so -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #7904 -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: I think you're saying that Cabal doesn't tell GHC to use the `cc-options` when assembling, and that Cabal has no `as-options`? I don't think that we want to change the GHC interface, so this would need to be fixed on the Cabal side. The Cabal bug tracker is here: https://github.com/haskell/cabal/issues In any case, I still don't think we want to do direct `.c` to `.o` compilation, which is what this ticket is about. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC