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

[GHC]

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

Comment (by rwbarton):

 Here is the disassembly of `stg_decodeFloatzuIntzh` from that build,
 annotated with my primitive understanding of ARM assembly. It's ... not
 right.
 {{{
 0000051c <stg_decodeFloatzuIntzh>:
      51c:       e2450004        sub     r0, r5, #4
         ; r0 = Sp - 4

      520:       e2458008        sub     r8, r5, #8
         ; r8 = Sp - 8    -- r8 happens to be R2, but irrelevant for now

      524:       ed058a01        vstr    s16, [r5, #-4]
         ; Sp[-4] = F1    -- Useless, and we haven't done the stack check
 yet!

      528:       e150000b        cmp     r0, fp
      52c:       3a000007        bcc     550 <stg_decodeFloatzuIntzh+0x34>
         ; if (Sp - 4 <= SpLim) goto gc;
         ; -- Not sure how it optimized Sp - 8 < SpLim to this, but looks
 correct.

      530:       eeb00a48        vmov.f32        s0, s16
         ; s0 = F1

      534:       e1a01008        mov     r1, r8
         ; r1 = Sp - 8
         ; -- At this point the args r0, r1, s0 are set up properly for the
 ccall.

      538:       ee187a10        vmov    r7, s16
         ; R1 = F1
         ; -- Very odd! This is the only time we set R1, but it should be
 set to Sp[-4]
         ; -- after the ccall!

      53c:       ebfffffe        bl      0 <__decodeFloat_Int>
                         53c: R_ARM_CALL __decodeFloat_Int
         ; ccall __decodeFloat_Int

      540:       e5988000        ldr     r8, [r8]
         ; R2 = Sp[-8]    -- good, but what about R1?

      544:       e5953000        ldr     r3, [r5]
         ; r3 = Sp[0]     -- return address

      548:       e12fff33        blx     r3
      54c:       e12fff1e        bx      lr
         ; return to r3 (this sequence is odd but apparently harmless, and
 used everywhere)

         ; gc branch follows
      550:       e59f500c        ldr     r5, [pc, #12]   ; 564
 <stg_decodeFloatzuIntzh+0x48>
      554:       e5885000        str     r5, [r8]
      558:       e1a05008        mov     r5, r8
      55c:       ebfffffe        bl      0 <stg_gc_noregs>
                         55c: R_ARM_CALL stg_gc_noregs
      560:       e12fff1e        bx      lr
 }}}

 May be a bug in GHC or LLVM. It would be nice to see the LLVM IR we
 output. What version of LLVM are you using, Ansible, amurrayc?

 I eyeballed the assembly for `__decodeFloat_Int` also and it appears
 correct at first glance.

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