#7297: LLVM incorrectly hoisting loads
-----------------------------------------+----------------------------------
Reporter: dterei | Owner: dterei
Type: bug | Status: new
Priority: normal | Component: Compiler (LLVM)
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime | Testcase: 367_letnoescape
Blockedby: | Blocking:
Related: |
-----------------------------------------+----------------------------------
Description changed by dterei:
Old description:
> test 367_letnoescape fails under LLVM as a load of the !HpLim register is
> hoisted out of the loop. So yielding is never done.
>
> What I am not sure about right now is the best way to fix. Loads in LLVM
> can be annotated in a few different ways to fix this and not sure which
> one is the most 'correct'.
>
> All the following work:
>
> * mark the load as volatile. (seems to give nicest code as well)
> * mark the load as atomic with either monotonic or seq_cst ordering.
> * mark the load as both volatile and atomic.
>
> This bug while only affecting a single test case seems very serious and
> potentially indicative of a large problem. How well are we communicating
> the load/store threaded semantics to LLVM?
>
> And what semantics do we need to communicate? I think we are fine other
> than the STG registers...
>
> So making a bug for now as I don't know yet the best way to proceed
> without dedicating some time to reading LLVM docs and probably talking to
> the LLVM devs as the docs on the memory model are fairly confusing.
New description:
test 367_letnoescape fails under LLVM as a load of the !HpLim register is
hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM
can be annotated in a few different ways to fix this and not sure which
one is the most 'correct'.
All the following work:
* mark the load as volatile. (seems to give nicest code as well)
* mark the load as atomic with either monotonic or seq_cst ordering.
* mark the load as both volatile and atomic.
This bug while only affecting a single test case seems very serious and
potentially indicative of a large problem. How well are we communicating
the load/store threaded semantics to LLVM?
And what semantics do we need to communicate? I think we are fine other
than the STG registers...
So making a bug for now as I don't know yet the best way to proceed
without dedicating some time to reading LLVM docs and probably talking to
the LLVM devs as the docs on the memory model are fairly confusing.
e.g., Code in question:
Bad version (LBB0_1 loops forever as load hoisted out):
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
movq 144(%r13), %rax
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header:
Depth=1
incq %r14
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}
Code when marked with atomic (either monatonic or seq_cst) or both atomic
and volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header:
Depth=1
incq %r14
movq 144(%r13), %rax
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}
Code when marked volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header:
Depth=1
incq %r14
cmpq $0, 144(%r13)
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}
--
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7297#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
