[GHC] #9125: int-to-float conversion broken on ARM

GHC ghc-devs at haskell.org
Thu Aug 7 15:49:29 UTC 2014


#9125: int-to-float conversion broken on ARM
-------------------------------------+-------------------------------------
              Reporter:  Ansible     |            Owner:
                  Type:  bug         |           Status:  infoneeded
              Priority:  highest     |        Milestone:  7.8.4
             Component:  Compiler    |          Version:  7.8.3
  (CodeGen)                          |         Keywords:
            Resolution:              |     Architecture:  arm
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Incorrect   |  Related Tickets:
  result at runtime                  |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 The Cmm code is fine. As far as I can tell, the .ll file is mostly fine
 except we do write to a memory location (the original Sp - 4) using TBAA
 metadata 1 and then later read from the same memory location (and LLVM
 knows it) using TBAA metadata 5. I lost my disassembly of the object file
 but it is wrong in a similar way to the assembly I annotated above: LLVM
 coalesces this store and read to a register move, presumably because it
 thinks for some reason that the intervening function call can not modify
 the memory. I don't see why it would assume this, but then again we did
 tell it via TBAA that two memory accesses would not alias that are in fact
 to the same address, so I suppose it is within its rights to do anything.

 amurrayc, can you try with this patch applied (effectively reverting
 e10589a505b44f4f0394500c6a0d2db5baa7f3f4):
 {{{
 diff --git a/compiler/llvmGen/LlvmCodeGen/Regs.hs
 b/compiler/llvmGen/LlvmCodeGen/Regs.hs
 index 0048659..d837d13 100644
 --- a/compiler/llvmGen/LlvmCodeGen/Regs.hs
 +++ b/compiler/llvmGen/LlvmCodeGen/Regs.hs
 @@ -101,11 +101,6 @@ stgTBAA
      , (heapN,  fsLit "heap",  Just topN)
      , (rxN,    fsLit "rx",    Just heapN)
      , (baseN,  fsLit "base",  Just topN)
 -    -- FIX: Not 100% sure about 'others' place. Might need to be under
 'heap'.
 -    -- OR I think the big thing is Sp is never aliased, so might want
 -    -- to change the hieracy to have Sp on its own branch that is never
 -    -- aliased (e.g never use top as a TBAA node).
 -    , (otherN, fsLit "other", Just topN)
      ]

  -- | Id values
 @@ -115,7 +110,7 @@ stackN = getUnique (fsLit "LlvmCodeGen.Regs.stackN")
  heapN  = getUnique (fsLit "LlvmCodeGen.Regs.heapN")
  rxN    = getUnique (fsLit "LlvmCodeGen.Regs.rxN")
  baseN  = getUnique (fsLit "LlvmCodeGen.Regs.baseN")
 -otherN = getUnique (fsLit "LlvmCodeGen.Regs.otherN")
 +otherN = topN

  -- | The TBAA metadata identifier
  tbaa :: LMString
 }}}

 If you can try a newer version of LLVM like 3.4, that would be great also.
 That version is newer than the admonitions to use 3.0 on the wiki page, so
 it's possible the LLVM bugs have been worked out in 3.4.

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


More information about the ghc-tickets mailing list