[GHC] #7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails

[GHC]

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails
---------------------------------+------------------------------------------
    Reporter:  thoughtpolice     |       Owner:  thoughtpolice      
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Milestone:                     
   Component:  Compiler (LLVM)   |     Version:  7.7                
    Keywords:                    |          Os:  MacOS X            
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
  Difficulty:  Unknown           |    Testcase:                     
   Blockedby:                    |    Blocking:                     
     Related:  #7571, #7575      |  
---------------------------------+------------------------------------------
Changes (by thoughtpolice):

  * owner:  dterei => thoughtpolice


Comment:

 I have fixed this bug. But I cannot quite answer your question.

 The bugfix: In a nutshell, if you look at that snipped I posted, the
 secret is the definition of ```exprToVar```:

 {{{
 exprToVar :: LlvmEnv -> CmmExpr -> UniqSM ExprData
 exprToVar env = exprToVarOpt env (wordOption (getDflags env))
 }}}

 The ```exprToVarOpt``` call essentially forces the return value of the
 expression. By default it is the word size of the build (64, here.) In
 this case, we detected that we needed to convert a i32 to an i64 (the ```w
 | w < toWidth``` branch.) So we execute ```sameConv'```, which invokes
 ```exprToVar```, which turns ```vx``` into an ```LlvmVar``` with a width
 of the *native* word size. Which in this case, is i64. So the check
 passes, but the variable we substitute for the coercion is of the wrong
 type. Annoying.

 The fix looks like this:

 {{{
 sameConv from ty reduce expand = do
             x'@(env', vx, stmts, top) <- exprToVarOpt env (EOption $ Just
 $ widthToLlvmInt from) x
             ...
 }}}

 I will create a patch and try to narrow down a test case. The patch I
 cooked up depends on #7571, which has a prerequisite patch and explanation
 of this same issue. I'll post it shortly.

 As for the cast, I am not precisely sure where it comes from. It comes
 from the ```MO_UU_Conv``` MachOp, which just does an unsigned -> unsigned
 conversion (optionally extending/truncating.) I don't know why it seems to
 be inserted for the store to ```Sp```.

 As for the loads/stores - isn't that natural? It looks fine to me. Before
 we pass code to ```opt```, the backend generates tons of loads and stores
 for all variable modification as opposed to using phi nodes for control
 flow. This is so that we can use the ```mem2reg``` pass in LLVM to
 essentially do the phi conversion for us, since we're essentially in CPS
 form at that point. The code generated by ```-ddump-llvm``` is of course
 before opt is run.

 Looking at the code, it seems pretty in line with the snippet of Cmm from
 the ```-ddump-cmm``` bit I posted, no?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7580#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler