Changes between Version 21 and Version 22 of PrimBool


Ignore:
Timestamp:
Aug 15, 2013 8:13:25 AM (23 months ago)
Author:
jstolarek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PrimBool

    v21 v22  
    7979There are five possible branches to take, although four of them have the same result. This is caused by code duplication introduced by case-of-case transform (see [http://lambda.jstolarek.com/2013/01/taking-magic-out-of-ghc-or-tracing-compilation-by-transformation/ this blog post] for a step by step derivation). According to Ben Lippmeier, who submitted the original bug report, mis-predicted branches are bad in object code because they stall the pipeline. 
    8080 
     81Note: this example was produced with GHC 7.6.3. At the moment of merging new primops into HEAD, there was no code duplication at the assembly level when using old primops. However, avoiding code duplication is not the main problem new primops are meant to solve. That problem are conditional branches.  
     82 
    8183== Solution == 
    8284 
     
    122124}}} 
    123125 
    124 Thanks to these wrappers the change is almost backwards compatible. '''The only thing primop users need to change in their existing code to make it work again is adding import of GHC.!PrimWrappers module.''' 
     126Thanks to these wrappers the change is almost backwards compatible. '''The only thing primop users need to change in their existing code to make it work again is adding import of GHC.!PrimWrappers module.''' The only exception are primops that operate on TVars, MVars and MutableArrays 
    125127 
    126128  * functions for comparing `Integer` type, implemented in integer-gmp and integer-simple libraries, received a similar treatment. Technically they are not primops, because they are implemented in Haskell (in case of integer-gmp also with FFI), but they pretend to be ones. There are six primops for comparing `Integer` values: