#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: #7571, #7575 --------------------------------+------------------------------------------- Comment(by thoughtpolice): There's logic to handle this in ```LlvmCodeGen.CodeGen``` but I'm not sure why it's not kicking in: {{{ sameConv from ty reduce expand = do x'@(env', vx, stmts, top) <- exprToVar env x let sameConv' op = do (v1, s1) <- doExpr ty $ Cast op vx ty return (env', v1, stmts `snocOL` s1, top) let toWidth = llvmWidthInBits dflags ty -- LLVM doesn't like trying to convert to same width, so -- need to check for that as we do get Cmm code doing it. case widthInBits from of w | w < toWidth -> sameConv' expand w | w > toWidth -> sameConv' reduce _w -> return x' }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: 7590 | Blocking: 7588, 7589 Related: #7571, #7575 | ---------------------------------+------------------------------------------ Changes (by bgamari): * cc: bgamari@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: 7590 | Blocking: 7588, 7589 Related: #7571, #7575 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): I'm a bit confused by your response. But it is my fault for not communicating better as I should have. For one, my OS X machine is running both 3.2 and 3.3svn, isolated. 3.2 is my primary installation. I mostly run both to narrow down bugs and out of curiosity, in this case it was identical output so there was otherwise no relevance. I should probably just not mentioned 3.3. I only have 3.3 for one personal thing I work on anyway. It's out of $PATH and out of mind. I just use 3.2 for everything else (including GHC.) Two, as for ARM, this ticket isn't about ARM? I imagine you meant #7575 where I do have a bug I found on ARM? And I'm not cross compiling in any of these tickets. I'm compiling on the ARM device itself with an existing 7.4.1 build provided by Ubuntu - so this would (I expect) work the same as any self-hosted 32bit build, modulo whatever ARM bugs I find. My ARM build of LLVM 3.3 is significantly older than what is in trunk now (because it takes a while to build,) and is much closer to the 3.2 branch. I can just put 3.2 on it anyway - I have a script to manually automate LLVM builds (and by default it just built trunk, not a released version. Likewise I am compiling here on OS X using LLVM 3.2. The host compiler is 64bit GHC 7.6.1. I am producing a 64bit compiler. The fix and patch for this issue were tested on that combo with that bootstrap compiler as well. For reference, here's the low down on my machines: Machine 1: 64-bit Quad core Mac OS X 10.8.2. ```xcodebuild -version``` reveals xcode version 4.5.2, build version 4G2008a. Host compiler is GHC 7.6.1, installed from a binary distribution. LLVM version is 3.2. This ticket is relevant to that. Machine 2: 32-bit Quad core ARM Linux. Ubuntu 12.10 derivative. GCC version is 4.6.3. LLVM version is 3.3svn as of about 3 weeks ago, but I'm going to replace that with 3.2 stable now. Bootstrap compiler is GHC 7.4.1 from Ubuntu repositories. Tickets #7571 and #7575 were filed against this machine. There is no cross compilation happening anywhere. All builds are standard with recent copies of HEAD. Karel Gardas has also reported success using my patch in #7571 for his ARM machine using LLVM 3.0, I believe. I reproduced #7571 with a hand-written Cmm file on OS X as well, which you [http://hackage.haskell.org/trac/ghc/attachment/ticket/7571/0001-Test-for- Trac-7571.patch can see in the ticket]. (Please try that test without this patch applied using the LLVM backend, and see if it fails.) I figured #7571 was probably due to the new code generator taking in a higher-level Cmm representation when parsing (because the bug came from the RTS, where a lot of Cmm was rewritten when the code generator went in.) I don't know what else to say - most of these are bugs long before the version of LLVM even matters as much. #7571 #7575 and this ticket are all outright compiler panics before code generation ever happen for me, so the actual version of LLVM doesn't seem as relevant. I unfortunately can't give you direct access to my machine OS X machine for various reasons. You are welcome to use my ARM machines if you'd like once I get them properly DMZ'd. Are there any other tests or examples you can think of? Could you try the testsuite test in #7571 with and without the patch? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: 7590 | Blocking: 7588, 7589 Related: #7571, #7575 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): I do use homebrew, but I do not ever manage my GHC installation with it. I just installed the 7.6.1 binary distribution from here: http://www.haskell.org/ghc/download_ghc_7_6_1#macosx_x86_64 I will get LLVM 3.1 working on my machine and see what happens when I bootstrap with it instead. I can also get 7.4.2 working and see if we can narrow a specific configuration down. Also, did you give a shot to the test I wrote in #7571 ? It should just be as easy as `ghc-stage2 -c -fllvm T7571.cmm` - This test should really be the ultimate clear case of whether one of these bugs does in fact manifest or not. It's worth noting that #7571 will ''only'' manifest during a bootstrap when the RTS is built in profiling mode, due to `#ifdef`ery in the Cmm files. I don't think you can avoid a profiling version of the RTS, but it's worth keeping in mind. I believe I also have an extra 'debug' patch for this ticket in my personal repository, that output a lot of helpful debugging info in tracking this down. I might dust it off, attach it, and step through what I see. Also if you'd like to contact me directly via email or through more instantaneous means (like an instant messaging system or IRC or something) to help sort it out quicker, you're more than free to (I'm CC'd on this ticket, so you can see my email there.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: 7590 | Blocking: 7588, 7589 Related: #7571, #7575 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): I need the patch in #7571 in order to get to this point on my OS X machine. #7575 is ARM (or 32bit) only it seems, so while related I think we can rule it out for the moment. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler