LLVM backend does not properly widen certain literal types in call expressions

Related to #7571 (closed) and #7574 (closed), while compiling stage2 with stage1 GHC HEAD on my ODROID, my build fails in libraries/base/GHC/Word.hs with:

linaro@linaro-ubuntu-desktop ~/code/ghc
 % "inplace/bin/ghc-stage1" -static  -H64m -O0 -fasm    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibrarie-Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCDl_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0  -package-name base -XHaskell98 -XCPP -O -fasm  -no -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/base/./files -tmpdir tmpdir                                                                                                                  
 
when making flags consistent: Warning:
    No native code generator, so using LLVM
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
/home/linaro/bin/opt: tmpdir/ghc12774_0/ghc12774_0.ll:26765:62: error: argument is not of expected type 'i64'
  %lnhvj = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnhvi, i32 0 ) nounwind

The declaration of ```hs_eqWord64` is:

{{{ declare ccc i32 @hs_eqWord64(i64, i64) align 4 }}}

And we get:

{{{ %lnhvj = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnhvi, i32 0 ) nounwind }}}

inside of c8Aq_info, which has a tail call from the symbol base_GHCziWord_zdfNumWord64zuzdcsignum_info or ```base_GHC.Word_

There was an error rendering this math block. KaTeX parse error: Expected group after '_' at position 11: fNumWord64_̲

csignum_info\` - this would seem to be some specialized instance of the case:

instance Num Word64 where
    ...
    signum 0               = 0
    signum _               = 1

1. .. I think. This seems like a fairly simple fix similar to the others, but I'm filing it for now.

Trac metadata

Trac field	Value
Version	7.6.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	dterei, simonmar
Operating system	Unknown/Multiple
Architecture	Unknown/Multiple

mentioned in issue #7571 (closed)

changed weight to 5

added Tbug Trac import labels

Word of note. I think I have a test for this:

{-# LANGUAGE MagicHash, UnliftedFFITypes #-}
module Main where
import GHC.Prim
import GHC.Word
import System.Environment (getArgs)

foreign import ccall unsafe "hs_eqWord64" dummy_eqWord64# :: Word64# -> Word64# -> Bool

check :: Word64 -> Word64 -> Bool
check (W64# x#) (W64# y#) = dummy_eqWord64# x# y#

main :: IO ()
main = do
  a <- (read . head) `fmap` getArgs
  print $ check a 0 

At -O2, with GHC 7.4.1 on ARM, this dumps code like:

...
%ln2EJ = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %ln2EI, i64 0 ) nounwind
...

So it seems like a regression. I'm rebuilding on my ODROID at the moment and will run this test with the stage1 compiler and see what happens. Intuition tells me this should trigger it based on the code I saw under base.

Also note that this will only affect 32 bit builds obviously. On 64bit machines, Word64 is native and does not shell out to long long and ghc-prim for Word64.

Trac metadata

Trac field	Value
Version	7.6.1 → 7.7
TypeOfFailure	OtherFailure → BuildingGhcFailed
Component	Compiler → Compiler (LLVM)
CC	dterei, simonmar → dterei, mad.one@gmail.com, simonmar

added LLVM backend ghc build failure + 1 deleted label

Trac metadata

Trac field	Value
TypeOfFailure	BuildingGhcFailed → CompileTimeCrash

Correction: this test correctly triggers the bug:

{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE MagicHash, UnliftedFFITypes #-}
module T7575 where
import GHC.Prim
import GHC.Word
import GHC.Types

foreign import ccall unsafe "hs_eqWord64" dummy_eqWord64# :: Word64# -> Word64# -> Bool

check :: Word64 -> Word64 -> Bool
check (W64# x#) (W64# y#) = dummy_eqWord64# x# y#

check2 :: Word64 -> Bool
check2 x = check x 0

Testing vs 7.4.1:

 $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
 $ ghc -c -O2 -fforce-recomp T7575.hs
 $ ~/code/ghc/inplace/bin/ghc-stage1 --version                 
The Glorious Glasgow Haskell Compilation System, version 7.7.20130113
 $ ~/code/ghc/inplace/bin/ghc-stage1 -c -O2 -fforce-recomp T7575.hs
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
/home/linaro/bin/opt: /tmp/ghc26188_0/ghc26188_0.ll:594:60: error: argument is not of expected type 'i64'
  %lnxh = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnxg, i32 0 ) nounwind
                                                           ^
 $ ~/code/ghc/inplace/bin/ghc-stage1 -c -O2 -fforce-recomp T7575.hs -pgmlo opt-3.0 -pgmlc llc-3.0
opt-3.0: /tmp/ghc26199_0/ghc26199_0.ll:594:60: error: argument is not of expected type 'i64'
  %lnxh = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnxg, i32 0 ) nounwind
                                                           ^
 $ 

So this is definitely a compiler regression in the backend somewhere.

Trac metadata

Trac field	Value
Operating system	Unknown/Multiple → Linux
Architecture	Unknown/Multiple → arm

mentioned in issue #7580 (closed)

mentioned in issue #7589 (closed)

Trac metadata

Trac field	Value
Blocking	→ #7589 (closed)

Trac metadata

Trac field	Value
BlockedBy	→ #7590 (closed)

mentioned in issue #7590 (closed)

Trac metadata

Trac field	Value
CC	dterei, mad.one@gmail.com, simonmar → bgamari@gmail.com, dterei, mad.one@gmail.com, simonmar

I discovered that when adding the signature

instance Num Word64 where
    (...)
    signum :: Word64 -> Word64
    (...)

and of course adding

{-# LANGUAGE InstanceSigs #-}

To Word.hs, it builds.

Trac metadata

Trac field	Value
BlockedBy	#7590 (closed) →
Blocking	#7589 (closed) → #7589 (closed), #7590 (closed)

mentioned in issue #7615 (closed)

Trac metadata

Trac field	Value
Blocking	#7589 (closed), #7590 (closed) → #7589 (closed)

mentioned in commit 1a703068

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label