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

29 Jul 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):

 I don't know whether this is the actual problem, but I think our TBAA is
 going wrong on this code.

 I tried to build GHC for Android with `-march=armv6`, so that it would use
 the floating point registers `s16` and so on. The build didn't finish for
 other reasons, but it got far enough to build `PrimOps.cmm`. Here is the
 `-ddump-cmm`:
 {{{
 ==================== Post CPS Cmm ====================
 [...]
  stg_decodeFloatzuIntzh() //  [F1]
          { info_tbl: []
            stack_info: arg_space: 0 updfr_space: Nothing
          }
      {offset
        c4w:
            F32[Sp - 4] = F1;
            Sp = Sp - 8;
            call block_c4o_info() args: 0, res: 0, upd: 0;
      }
  },
  block_c4o_entry() //  []
          { info_tbl: [(c4o,
                        label: block_c4o_info
                        rep:StackRep [True])]
            stack_info: arg_space: 0 updfr_space: Nothing
          }
      {offset
        c4o:
            if ((Sp + 4) < SpLim) goto c4q; else goto c4r;
        c4q:
            I32[Sp] = block_c4o_info;
            call stg_gc_noregs() args: 4, res: 4, upd: 4;
        c4r:
            _c4k::I32 = Sp + 4;
            call "ccall" arg hints:  [PtrHint,
                                      PtrHint,]  result hints:  []
 __decodeFloat_Int(_c4k::I32, Sp, F32[Sp + 4]);
            R2 = I32[Sp];
            R1 = I32[_c4k::I32];
            Sp = Sp + 8;
            call (P32[Sp])(R2, R1) args: 4, res: 0, upd: 4;
      }
  },
 }}}

 What's unusual about this is that R1 is read by dereferencing the variable
 `_c4k`, even though the address it points to lives on the stack. This
 violates the assumptions made by our TBAA:
 https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alia...
 And indeed, in the `.ll` file, the read of R2 is done using the "stack"
 type, but the read of R1 is done using the "other" type, which supposedly
 cannot alias the "stack" type.

 However, while it seems potentially relevant, I don't see specifically how
 this could cause our problem. (And my LLVM produced the correct assembly
 for `stg_decodeFloatzuIntzh`.)

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