I don't think we should. We should either call the C based fallback implementation in the ghc-prim package or the popcnt instruction. The Haskell implementation in the test is a toy that should only be used to validate that the primop computes the right result. If the instruction is being incorrectly used when it's not available we should fix that.
On Thu, Sep 5, 2013 at 9:47 AM, Muhaimin Ahsan <[email protected]> wrote: > I'm asking if we should call it in the real implementation of the PrimOp. > This isn't a problem across all platforms; it's specific to apple-gcc42, I > believe based on yesterday's findings. I'll continue working on it later > today. Also, I'm extremely new to GHC internals (this is the second bug I'm > tackling), so I may be viewing things the wrong and would appreciate pointers. > > Muhaimin Ahsan > > On Sep 5, 2013, at 9:09 AM, Johan Tibell <[email protected]> wrote: > >> On Thu, Sep 5, 2013 at 12:20 AM, GHC <[email protected]> wrote: >>> Should we switch to calling the "slower" popCount for this certain case? >>> https://github.com/ghc/testsuite/blob/master/tests/codeGen/should_run/cgrun071.hs#L41-L46 >>> {{{ >>> slowPopcnt :: Word -> Word >>> slowPopcnt x = count' (bitSize x) x 0 >>> where >>> count' 0 _ !acc = acc >>> count' n x acc = count' (n-1) (x `shiftR` 1) >>> (acc + if x .&. 1 == 1 then 1 else 0) >>> }}} >> >> I've not been following this closely so apologies if I've >> misunderstood the issue. >> >> Are you asking if we should call slowPopcnt in the test in more >> circumstances or if we should call it in the real implementation of >> the primop? The primop already has a fallback if the popcnt >> instruction isn't available (it uses a table-based implementation). >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
