[GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen

[GHC]

#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