- ghc-tickets - Haskell.org

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 24 May '14

24 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dterei): I'm very in support of getting rid of the mangler. I just don't think we can given what LLVM supports today. I may be wrong about Windows, but I thought someone added support to the mangler to handle some Windows specific issues. I had forgotten about the OSX alignment issue, so that is one other use case. Perhaps the LLVM API would allow this, I didn't think it was more expressive than the LLVM language but haven't checked. It's worth playing around with this new function data prefix if you have the inclination just to see what we can get done with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): Replying to [comment:20 dterei]: > The other issue is that fixing TNTC doesn't eliminate the mangler. We use it for a few different reasons now. I can think of at least 3 I believe: TNTC, SIMD, and Windows. I didn't know the mangler is used for Windows, though I recall it was (is?) used for stack alignment on OSX. I was hoping that a move to using the LLVM API would allow enough control to be rid of the mangler once and for all, but it seems the idea is not getting much traction. I may press on in my own tree to gather some stats and become more familiar with LLVM's internals. Maybe it'll bear some unexpected fruit. Cheers, Will -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): Is there any reason to not propose to change LLVM's prefix semantics such that the function's symbol points to the function body rather than the prefix data? To keep the optimization passes happy, it seems like one could have symbols for both the prefix data and the function body. The prefix data seems to be stuffed in a return instruction, so I'd think with both symbols, dead code elimination and other optimization passes wouldn't mess with the prefix data. I see two advantages to this approach: • no extra unconditional branch • prefix would no longer require the front end to construct target specific instructions -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dterei): Firstly, its cool that LLVM has added this. It seems we could indeed implement TNTC with it. However based my quick understanding we couldnt implement it in a wag compatible with the current design. I believe the LLVM feature only allows us to place data at the very start of the function, after the label not before it. And your meant to ensure the very first instruction of the function is a jump that jumps over the data. We could use this, Simon Marlow and I discussed such a design in the past. But it's a change from the current scheme so the NCG would also need to change and it isn't clear if it would be as good as our current design. The other issue is that fixing TNTC doesn't eliminate the mangler. We use it for a few different reasons now. I can think of at least 3 I believe: TNTC, SIMD, and Windows. As for moving to the LLVM api. No, I think that isn't a great idea. I'm not convinced its will gain much compilation speed improvement. This is testable vy measuring how much time is actually spent invoking the LLVM binaries and how much time they spend serializing and parsing files. Given we need to go to an intermediary file of assembly for the mangler... Using the API also creates a GHC build time dependency on LLVM. Right now we avoid that which has advantages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 23 May '14

23 May '14

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by slyfox): * cc: simonmar (added) * difficulty: => Unknown Comment: 0001-rts-posix-Select.c-remove-unused-select_succeeded.patch is a cleanup patch removing unused variable 0002-rts-posix-Select.c-search-for-EBADFs.patch is a patch, that finds bad file descriptors passed to select() What is the easiest way to convert such TSOs into IOException thunks? Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): Re. patching LLVM: Are there any other uses of the symbol offset feature than fixing the symbols for functions that use prefix data? If not, how about patching the LLVM prefix code to accept an option (a bool) to have symbols point to the function entry? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by altaic): Yikes, I'm definitely not suggesting mangling the object file! I'd like to be rid of manglers entirely. Replying to [comment:15 bgamari]: > In my opinion, it would be wise to avoid linking against LLVM. Any particular reason? In my experience (which is probably much more limited than yours), getting upstream patches accepted is much more difficult, especially if there is a workaround. In addition, one of the main downsides of the LLVM backend is that compile time is much slower. Linking against LLVM would improve compilation time, make mangling unnecessary, and there may be other advantages as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1
by GHC 23 May '14

23 May '14

#9104: internal compiler error: Segmentation fault for haskell-src-exts-1.15.0.1 ----------------------------------+--------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- {{{ amy@wombat$ cabal --no-require-sandbox install haskell-src-exts-1.15.0.1 Resolving dependencies... Configuring haskell-src-exts-1.15.0.1... Building haskell-src-exts-1.15.0.1... Failed to install haskell-src-exts-1.15.0.1 Last 10 lines of the build log ( /home/amy/.cabal/logs/haskell-src- exts-1.15.0.1.log ): [22 of 22] Compiling Language.Haskell.Exts ( src/Language/Haskell/Exts.hs, dist/build/Language/Haskell/Exts.o ) [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc23747_0/ghc23747_3.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions. cabal: Error: some packages failed to install: haskell-src-exts-1.15.0.1 failed during the building phase. The exception was: ExitFailure 1 }}} {{{ amy@wombat$ cabal --version cabal-install version 1.21.0.0 using version 1.21.0.0 of the Cabal library }}} {{{ amy@wombat$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure'
by GHC 23 May '14

23 May '14

#9129: link error: unknown symbol `diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure' ----------------------------------+------------------------------------- Reporter: dmbergey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- When trying to build libraries linking against https://github.com/diagrams /diagrams-lib/tree/direction I get an error, in both GHC 7.6.3 and GHC 7.8.2. In 7.6.3: `Loading package diagrams-lib-1.1.0.1 ... linking ... ghc: /home/vagrant/.cabal/lib/diagrams-lib-1.1.0.1/ghc-7.6.3/HSdiagrams- lib-1.1.0.1.o: unknown symbol \`diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_closure'` In 7.8.2: `Loading package diagrams-lib-1.1.0.1 ... <command line>: can't load .so/.DLL for: /home/bergey/code/diagrams/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.2/diagrams-lib-1.1.0.1/libHSdiagrams-lib-1.1.0.1-ghc7.8.2.so (/home/bergey/code/diagrams/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.2 /diagrams-lib-1.1.0.1/libHSdiagrams-lib-1.1.0.1-ghc7.8.2.so: undefined symbol: diagramszmlibzm1zi1zi0zi1_DiagramsziDirection_Direction_con_info)` The problem seems specific to this branch. I can install the package, but cannot link against it. The following steps reproduce the error in a clean Linux (Ubuntu) VM with HP 2013.2 installed: set -e sudo aptitude install git -y git clone https://github.com/diagrams/diagrams-core.git core git clone https://github.com/diagrams/diagrams-lib.git lib git clone https://github.com/diagrams/diagrams-svg.git svg cabal update cd lib/ git checkout direction cd .. cabal install core/ lib/ svg/ I'm happy to do more debugging if someone can advise me what to try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 23 May '14

23 May '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): If we mangle the symbol table of the output .o file then it will be too late for intra-module references to be fixed up. So either we need to mangle the assembly anyways, or we need to adjust the input to LLVM taking this into account. That means when we build a thunk, we need to obtain the pointer to the end of the info table, which will be the symbol as known by LLVM plus some constant, but only when the symbol is in the current module; and when we want to jump to another function we need that function to start with one of these little jmps to skip the info table, since we can't tell LLVM to do a jump to a symbol plus some random byte offset. The symbol offset approach sounds workable to me. I assume it's not possible to tell LLVM to emit a global symbol in the middle of a function, as a second entry point? That would also solve our problem, as we could then stick the _info symbol after the prefix data and use it (rather than the symbol for the function, which points to the start of the info table) for building thunks and calling as usual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0