Does not build on powerpc about hashtables

[nomeata]

One might think that it would potentially affect all 32-bit-architectures without a native code generation, but it builds on other arches as well (but no idea if it actually works there. A test suite using the Cabal test (documented in http://www.haskell.org/cabal/users-guide/developing-packages.html#test-suites) would be helpful here):
https://buildd.debian.org/status/package.php?p=haskell-hashtables

[nomeata]

Bug crossreference: http://bugs.debian.org/669227

[gregorycollins]

Try passing in -fportable. Let me know if that works.

G

On Wed, Apr 18, 2012 at 11:19 AM, nomeata <
[email protected]

wrote:

Hi,

hashtables does not build on a powerpc machine, for a build log see

https://buildd.debian.org/status/fetch.php?pkg=haskell-hashtables&arch=powerpc&ver=1.0.0.0-2&stamp=1330002314

Do you think you can fix that?

Thanks,
Joachim

---

Reply to this email directly or view it on GitHub:
#4

Gregory Collins [email protected]

[nomeata]

No, that does not help.

Looking at the assembly code, the the culprit is definitely highestBitMask, with the instruction

    lwz     3, 3(14)
    lwz     4, 3(14)
    srwi    4, 4, 1
    or      4, 3, 4
    srwi    3, 4, 2
    or      4, 4, 3
    srwi    3, 4, 4
    or      4, 4, 3
    srwi    3, 4, 8
    or      4, 4, 3
    srwi    3, 4, 16
    or      4, 4, 3
    srwi    3, 4, 32
    or      4, 4, 3
    lis     3, base_GHCziWord_Wzh_con_info@ha

I find it strange, though, that the same code does not cause errors in the containers library. If I look at the assembly generated for Data.IntSet, I do see the series of srwi instructions, but it is missing the 32:

    lwz     3, 20(22)
    lwz     4, 11(14)
    xor     4, 3, 4
    srwi    3, 4, 1
    or      4, 4, 3
    srwi    3, 4, 2
    or      4, 4, 3
    srwi    3, 4, 4
    or      4, 4, 3
    srwi    3, 4, 8
    or      4, 4, 3
    srwi    3, 4, 16
    or      5, 4, 3
    lwz     3, 16(22)

Ah, but actually, the functions are defined slightly differently. You do:

{-# INLINE highestBitMask #-}
highestBitMask :: Word -> Word
highestBitMask !x0 = case (x0 .|. shiftRL x0 1) of
                  x1 -> case (x1 .|. shiftRL x1 2) of
                   x2 -> case (x2 .|. shiftRL x2 4) of
                    x3 -> case (x3 .|. shiftRL x3 8) of
                     x4 -> case (x4 .|. shiftRL x4 16) of
                      x5 -> x5 .|. shiftRL x5 32

but containers has:

highestBitMask :: Nat -> Nat
highestBitMask x0
  = case (x0 .|. shiftRL x0 1) of
     x1 -> case (x1 .|. shiftRL x1 2) of
      x2 -> case (x2 .|. shiftRL x2 4) of
       x3 -> case (x3 .|. shiftRL x3 8) of
        x4 -> case (x4 .|. shiftRL x4 16) of
         x5 -> case (x5 .|. shiftRL x5 32) of   -- for 64 bit platforms
          x6 -> (x6 `xor` (shiftRL x6 1))
{-# INLINE highestBitMask #-}

Hmm, but even copying that code into Utils.hs does not help. Ah, here is the reason: You use uncheckedShiftRL# while containers use shiftRL#. Changing this makes the program compile. And indeed the documentation predicted the problem:

primop   SrlOp   "uncheckedShiftRL#"   GenPrimOp   Word# -> Int# -> Word#
     {Shift right logical.   Result undefined if shift  amount is not
      in the range 0 to word size - 1 inclusive.}

Now, as long as all your calls to shiftRL have a known second argument, using shiftRL# should cost no run-time performance over uncheckedShiftRL#. Grepping through your code, this seems to be the case. Therefore, I suggest you do that.

Thanks,
Joachim

[gregorycollins]

I checked the assembler output, and going from unchecked to checked shifts
changes an "shrq" assembly instruction to a function call, so that won't
fly. I'll fix this some other way.

[gregorycollins]

Never mind, I lied -- I forgot to pass -O2 when making the assembler output

[gregorycollins]

Released as 1.0.1.4 -- please try again?

[nomeata]

Yes, I could compile it on a powerpc machine without issues, and will upload it to Debian now. Thanks for your help!