#9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 4213 | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Altaic, thanks for writing these down! I'd just like to mention one further complication (and please someone correct me if I'm wrong here): It's not sufficient to just match up definitions and calls as in some cases (e.g. symbols defined outside of the current compilation unit) we will never see the definition we are looking for. In the case of functions, we can sometimes infer the type with the information in a `CmmCall` node, but as far as I can tell there's no guarantee that we will ever see one of these (e.g. we may only see the symbol in a `CmmLabel` node within an expression). My thoughts on these options are, 1. In light of the external symbol problem, I'm not convinced it's worth paying this much to back out types for LLVM. The compiler has already demonstrated that the program is well-typed so the exercise doesn't gain us any safety (other than rejecting the occasional code generator bug). 2. See above 3. Eww. 4. I don't know how much work this work be either. Unless there's some user for this sort of information in downstream consumers other than the LLVM codegen I'm not convinced we want to go this route. 5. An interesting idea that I hadn't considered. Perhaps if the C-- lowering code were refactored a bit the code duplication could be reduced. Perhaps (4) is better in this case? Either way, this sounds like a lot of work for relative little benefit (could LLVM better optimize the STG representation? I suspect not; C-- is about the right level of abstraction for LLVM's IR). 6. This is probably the most likely option. I've been doing a pretty poor job in conveying our needs the LLVM folks but we'll see what they say. Our usecase doesn't seem too outlandish so there should be a path forward one way or another. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9142#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler