[GHC] #9125: int-to-float conversion broken on ARM
GHC
ghc-devs at haskell.org
Tue Jul 29 16:06:47 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):
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/Alias#HowtoTrackTBAAinformation
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
More information about the ghc-tickets
mailing list