- 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 altaic): Replying to [comment:31 bgamari]: > I could be mistaken but I don't believe this should be necessary with symbol offsets as the inliner won't see the info table at all (since the symbol points to the entrypoint of the function as it should). Oh, that sounds right. Cool. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:32> 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:30 altaic]: > I pointed out two shortcomings of the current semantics already. Even with the proposed symbol offsets, the prefix data must start with a target-dependent frontend-constructed instruction, which is subsequently not used. I.e. it requires carefully constructed garbage bytes. To me, that sounds kind of... not good. I could be mistaken but I don't believe this should be necessary with symbol offsets as the inliner won't see the info table at all (since the symbol points to the entrypoint of the function as it should). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:31> 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 altaic): Replying to [comment:24 bgamari]: > 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. An already released feature which is likely to have yet to be used in the wild. > Especially when there is nothing wrong with the existing semantics. I pointed out two shortcomings of the current semantics already. Even with the proposed symbol offsets, the prefix data must start with a target- dependent frontend-constructed instruction, which is subsequently not used. I.e. it requires carefully constructed garbage bytes. To me, that sounds kind of... not good. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:30> 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): So I haven't looked at the proposed offsetting feature for LLVM. If that feature indeed means we can support TNTC without any changes to our current design (i.e., no changes to NCG or RTS) then awesome! We should defiantly make that change. I agree that minimizing how much we use the mangler is a good thing. If we can remove it then we should be able to avoid any intermediate files at all other than the .ll file. It's silly right now that we run `opt` and produce an intermediate .bc file, and then run `llc`. We should be able to just use a driver to go from .ll to an object file. At that point I'd be very surprised if changing to the LLVM API had any advantage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:29> 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 altaic): Replying to [comment:26 awson]: > Now LLVM-compiled 64-bit code [https://ghc.haskell.org/trac/ghc/ticket/8974 segfaults on Windows]. I've prepared the patch, but [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:10 I don't know the way to implement it without mangler] because LLVM does not want to silently truncate 64-bit address constant to 32-bit but bitwise ands it with `-1` (`&-1`) also. Ah, my apologies, I'm not sure why your ticket didn't appear on my trac query. LLVM does have a {{{trunc .. to}}} instruction, which may be of use to you, though admittedly I don't really know what's going on in your ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks
by GHC 24 May '14

24 May '14

#8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Are we going to make available directions so that people can use 7.6 correctly with xcode 5 and/or mavericks? eg: will we provide directions to either 1. use Luke Ianni's clang wrapper hack, and bundle that with a 7.6 release thats 7.6.3 + that extra binary to make a 10.8 friendly "stability" release 2. tell people to stick to xcode 4.6 and/or install a newer GCC (say, GCC 4.8) and adjust their ghc settings file to point to that other GCC? We need to provide this information in a clear way, because this WILL be a problem where we'll have a support load from it (whether we want to or not, until GHC 7.8 gets a haskell platform release, this WILL happen. We need to have a mitigation strategy so that we aren't dealing with it constantly) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

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): For the record, the current state of my experiments with implementing TNTC on top of LLVM's new IR features can be found here, https://github.com/bgamari/ghc/compare/ghc:ghc-7.8...llvm-demangle. Note that this needs to be used with my llvm branch for symbol offset support, https://github.com/bgamari/llvm/compare/symbol-offset -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:27> 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 awson): Replying to [comment:25 altaic]: > I also couldn't find anything WRT Windows and the mangler. Now LLVM-compiled 64-bit code segfaults on Windows. I've prepared the patch, but [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:10 I don't know the way to implement it without mangler] because LLVM does not want to silently truncate 64-bit address constant to 32-bit but bitwise ands it with `-1` (`&-1`) also. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:26> 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 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