Re: [GHC] #14361: GHC HEAD miscompiles `text-containers`

4 Nov 2017

      #14361: GHC HEAD miscompiles `text-containers`
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 One thing that I've noticed while looking at the Core here I noticed what
 I believe is a slight performance papercut in our Core: In the Core we
 essentially have this:
 {{{#!hs
 data IdxOfsLen = IdxOfsLen !Int !Int !Int
 }}}

 Inside of `lookupIndexNear` we end up with a join point:
 {{{#!hs
 $j_sjcd [Dmd=]
   :: GHC.Prim.Int#
      -> GHC.Prim.Int# -> GHC.Prim.Int# -> IdxOfsLen -> LRes
 [LclId[JoinId(4)],
  Arity=4,
  Str=,
  Unf=OtherCon []]
 $j_sjcd (ww5_scRL [OS=OneShot] :: GHC.Prim.Int#)
         (ww6_scRM [OS=OneShot] :: GHC.Prim.Int#)
         (ww7_scRN [OS=OneShot] :: GHC.Prim.Int#)
         (ww4_scRK [OS=OneShot]
            :: IdxOfsLen
            Unf=OtherCon [])
   = case Internal2.$wcmpBA2OfsLen y_a4lB ww_sjnB ww6_scRM ww7_scRN
     of {
       LT -> Data.TextSet.Unboxed.LResBelow ww4_scRK;
       EQ -> Data.TextSet.Unboxed.LResExact ww4_scRK;
       GT -> {- some expression with no dependence on any of the above
 arguments -}
 }}}

 Where the call sites all look like,
 {{{#!hs
 jump $j_sjcd
   a b c (Internal.IdxOfsLen a b c)
 }}}
 That is, we essentially pass the same arguments twice, once unboxed and
 once inside a `IdxOfsLen` constructor. It seems the reason for this is
 that we always need the unboxed values for the call to `$wcmpBA2OfsLen`
 but also sometimes need the `IdxOfsLen`. It seems like it would be better
 to either only pass the constructor and extract the needed values out of
 it inside the join point, or to only pass the unboxed arguments, and
 construct the constructor when needed.

 I doubt this makes much of a difference in this particular case, but I
 suspect there are others where it will matter quite a bit.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14361#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler