Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals

#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
participants (1)
-
GHC