May 2014 - ghc-tickets

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 altaic): Replying to [comment:23 dterei]: > I'm very in support of getting rid of the mangler. FWIW, I just had a peek at the mangler, and it appears that it is now only used for TNTC and stack alignment. I also looked for references to the mangler with respect to SIMD in the wiki, but couldn't find anything other than a blank section [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Man… here]. I also couldn't find anything WRT Windows and the mangler. Finally, according to #4211 (as of commit 8a1c644af72caf122e73dac801496c055fc82dd9), the mangler is no longer needed to fix the stack on OSX. If true, completing this ticket may be the end of the mangler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:25> 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 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 bgamari): '''Replying to [comment:21 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? I hope that the LLVM folks would reject outright any proposal to change the semantics of an already released feature in a non-compatible way. Especially when there is nothing wrong with the existing semantics. '''Replying to [comment:19 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? As I understand it, the proposals were designed explicitly to keep the matters of prefix data and symbol offsets orthogonal. In my opinion this was the right decision, even if it does require a bit more work. The only issue here is that symbol offset support was never implemented. I have a patch for this although it needs a little reworking. '''Replying to [comment:20 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. See above. There is no reason why TNTC can't be implemented once symbol offsets are in place. Your points surrounding the mangler's other roles are valid but I'd still say we should start trimming it where we can. If we can support TNTC without shuffling sections around, we are a little closer to deprecating the mangler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:24> 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 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