
#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): I have implemented the changes. Now I am left with cleaning up the code, writing more tests and verifying that there are no performance regressions. This will take some more time, but I would like to ask how should I prepare my patches (there will be a total of 7: ghc, testsuite and libraries: base, ghc-prim, integer-gmp, integer-simpl and primitive). Should I squash all the commits in my branches into one big commit or can I leave the commits as they are (or perhaps squash them selectively)? Which user documentation, if any, should I update (aside from the wiki page)? What information should be documented in the source code? There is one thing I wasn't able to implement the way I think it should be: constant folding for Integer. Each comparison function for Integer is now split into a primop, which returns an Int#, and a wrapper, which calls tagToEnum# and returns a Bool. The constant folding rules for Integer are working on the wrappers, so that whenever somebody writes ((1 :: Integer) == 1) it gets constant folded to True. This works properly and doesn't break any existing code, but is inconsistent with the rules for other comparisons, which are defined for primops, not for their wrappers. So the call to "`eqInteger 1 1`" (the wrapper) gets constant folded, while the call to "`eqInteger# 1 1`" (the primop) doesn't. I have run into problems with this (posted on ghc-devs on May 16th) and I don't know how to fix this. What is others' opinion on accepting the patches with this defect and opening a separate ticket for constant folding of Integer primops? I actually don't like that idea, but I'm afraid I might be stuck on this one for another 2 or 3 weeks - it would be a lot easier for me to push all the changes I have been making and then focus solely on Integer constant folding. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6135#comment:52 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler