[GHC] #9504: LLVM backend TBAA is too aggressive

[GHC]

#9504: LLVM backend TBAA is too aggressive
-------------------------------------+-------------------------------------
       Reporter:  rwbarton           |                   Owner:
           Type:  bug                |                  Status:  new
       Priority:  normal             |               Milestone:
      Component:  Compiler (LLVM)    |                 Version:  7.8.3
       Keywords:                     |        Operating System:
   Architecture:  Unknown/Multiple   |  Unknown/Multiple
     Difficulty:  Unknown            |         Type of failure:  Incorrect
     Blocked By:                     |  result at runtime
Related Tickets:                     |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
 At
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation
 there is written

 > It [a memory load/store] is very rarely of the form:
 > {{{
 > x = Sp + 8
 > I64[x] = ...
 > }}}
 > And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer,
 "stack" pointers are always of the in-line variety.

 In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory
 access through a Cmm local variable as having the "other" type, which
 cannot alias any non-"other" address.

 But it turns out that a Cmm local might be either an offset from Sp
 (#9125, though TBAA doesn't seem to have been the cause of the bad code
 there) or an offset from a Cmm global variable (#9308). In general, we
 don't know anything about what it might be so we should conservatively use
 the "top" "type".

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9504>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler