August 2016 - ghc-tickets

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): It seems to work. I added a pass before generating byte-code which transforms the unboxed tuples and now ghci works again. I am validating right now, but stage2 was working, so this should pass, too. So to let you review my changes, I have to ask: Should I include changes made to submodules or just include the changes to GHC? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1475: Adding imports and exports with Template Haskell
by GHC 02 Aug '16

02 Aug '16

#1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomasjm): Replying to [comment:19 SimonHengel]: > Just because I've been pushing for this in the past, I solved my use case in a different way. > > For me closing this as won't fix would be ok. @SimonHengel, I'd like to do the same use case of generating test imports automatically. Could you describe how you solved the problem? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1475#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2333: Emit a warning if an INLINE function is a loop breaker
by GHC 02 Aug '16

02 Aug '16

#2333: Emit a warning if an INLINE function is a loop breaker -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: We have done this for a very long time now. In fact there are even tickets about these warnings (#9418). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2333#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > E.g. turn foo (# a, b, c #) into foo a b c Yes. That's the easy part (see `RepType.repType`), the problem is returning tuples, it needs support from the code generator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): After switching to {{{(# Int#, Addr# #)}}}, I have a sort-of working implementation. The builtin rules seem to work, rewriting string literals from user-code works and has access to the length, but ghci wouldn't even start up. Maybe I can take a look this evening into it, but if I understand unboxed tuples correctly, it should be possible to just flatten them if they appear in an argument position, right? E.g. turn {{{ foo (# a, b, c #) }}} into {{{ foo a b c }}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I didn't follow the whole thread but yeah, if you want to compile string literals to unboxed tuples (`(# len, ptr #)`) it'd be a problem for GHCi as the bytecode interpreter/compiler can't handle unboxed tuple returns. (it has some special cases for handling primops that return state tokens in an unboxed tuple) We had briefly discussed doing bytecode generation after unarise in the mailing list (https://mail.haskell.org/pipermail/ghc- devs/2016-July/012502.html see Simon's response). I don't understand native calling conventions good enough to comment, but maybe we can add one more special case in the bytecode compiler to handle `(# len, ptr #)` returns, like the special cases for returning `(# RealWorld#, a #)` etc. (search for `isUnboxedTupleCon` in `ByteCodeGen.hs`) I'm willing to work on extending unboxed tuple support in the bytecode interpreter, but I don't have any concrete proposals right now -- I need to study native calling conventions for returning tuples first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The Unarise pass removes unboxed tuple binders and arguments, so it would be passed as two separate arguments. However, unarise is currently part of SimplStg, so GHCi doesn't get to take advantage of it, I don't know how hard that is to change. Maybe @osa1 or @simonpj would know. Backwards compatibility is a separate issue, we can always introduce new APIs instead of breaking old ones, I doubt there are serious problems here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Wouldn't that generate something like {{{unpackCString# (# 3#, "abc"# #)}}} for {{{"abc"}}}? And if I just typed "abc" in ghci, wouldn't it fail as ghci can not handle unboxed tuples? Beside from that, it should work, but then I could also just try to change {{{unpackCString#}}} to have type {{{Addr# -> Int# -> [Char]}}}, avoiding the tuple. This would of course break backwards compatibility, as would an unboxed tuple, and I wanted to see if I could avoid that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Doesn't it work to have string literals be of type `(# Int#, Addr# #)` (see comment:38)? The unboxed tuple will be passed as two arguments, but in Core you can name the unboxed tuple and pass it around as a single entity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0