Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,252
    • Issues 5,252
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 561
    • Merge requests 561
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #7297
Closed
Open
Issue created Oct 04, 2012 by dterei@trac-dterei

LLVM incorrectly hoisting loads

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
Edited Mar 09, 2019 by dterei
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking