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 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 wrote:

...

On Thu, Sep 5, 2013 at 12:20 AM, GHC wrote:

...

Should we switch to calling the "slower" popCount for this certain case? https://github.com/ghc/testsuite/blob/master/tests/codeGen/should_run/cgrun0... {{{ 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs