Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Value stack underflow during JIT compilation (AB AB problem) #2

Closed
kpp opened this issue Sep 9, 2013 · 1 comment
Closed

Value stack underflow during JIT compilation (AB AB problem) #2

kpp opened this issue Sep 9, 2013 · 1 comment
Labels
Milestone

Comments

@kpp
Copy link
Collaborator

kpp commented Sep 9, 2013

The problem is in MethodCompiler::TJITContext::popValue due to the linkage of Smalltalk stack with LLVM IR tree during JIT compilation.

Code to reproduce the bug:

Jit do: [ BranchTest new phi ].

METHOD BranchTest
phi |x|     
    x <- (true ifTrue:  [ 11 ]
               ifFalse: [ 17 ] ) +
         (true ifTrue:  [ 13 ]
               ifFalse: [ 15 ] ).

    [ x ] assertEq: 24.
!

Bytecode:

0000 PushConstant true
0001 DoSpecial branchIfFalse 8
0004 PushLiteral 0         ; SmallInt 11
0005 DoSpecial branch 9
0008 PushLiteral 1         ; SmallInt 17
0009 PushConstant true
0010 DoSpecial branchIfFalse 17
0013 PushLiteral 2         ; SmallInt 13
0014 DoSpecial branch 18
0017 PushLiteral 3         ; SmallInt 15
0018 SendBinary +
0019 AssignTemporary 0
0020 DoSpecial popTop
0021 PushBlock
0024     PushTemporary 0
0025     DoSpecial stackReturn
0026 PushLiteral 4         ; #assertEq:
0027 MarkArguments 2
0028 SendMessage assertEq:
0029 DoSpecial popTop
0030 DoSpecial selfReturn

The compiler links BBs together with "MethodCompiler::TRefererSet referers" in a linked tree:

A   B    A   B
 \ /      \ /
  C        D
   \      /
     \  /
       E

As you can see, there is a duplicate of AB part, which leads to stack underflow.
JIT compiler produces the following pseudocode:

A: push
B: push
C: push
D: push

E: pop -> phi C , D
E: pop -> phi -> C  pop -> phi A, B
                 D  pop -> Value stack underflow

The compiler should link BBs in the following way:

A   B    C   D
 \ /      \ /
  *        *
   \      /
     \  /
       E

E: pop -> phi A , B
E: pop -> phi C , D
@0x7CFE
Copy link
Owner

0x7CFE commented Apr 22, 2014

This bug is highly related to current implementation of MethodCompiler.

The upcoming instruction API in #32 will eliminate it automagically because of new graph representation of control flow.

kpp added a commit that referenced this issue Jun 12, 2014
kpp added a commit that referenced this issue Jun 12, 2014
kpp added a commit that referenced this issue Jun 12, 2014
kpp added a commit that referenced this issue Jun 12, 2014
0x7CFE added a commit that referenced this issue Jun 13, 2014
Previous implementation incorrectly processed
block chains with non-empty stacks.

Consider the following situation:
	A(-2) <- B(1) <- C(1)

Block A is the value consumer which requests two values
from the refering blocks. Each of blocks B and C provide
a single value on their local stack.

First request with index 0 will be satisfied by block B
because it has 1 value on the local stack.

Request with index 1 is more complex. First, block A looks
into block B because it is the only referer. But block B
have only 1 value on the stack and therefore could not
provide a value with index 1. Hence, block C is queried
recursively.

The problem is that block C also have only 1 value and
could not satisfy request with index 1.

Problem is solved by substracting the size of local stack
from the requested index on each recursion entry.

Finally, second value will be requested from block C
with effective index 1 - 1 = 0.

Issue: #32
Issue: #2
0x7CFE added a commit that referenced this issue Jun 14, 2014
Previous implementation incorrectly processed
block chains with non-empty stacks.

Consider the following situation:
	A(-2) <- B(1) <- C(1)

Block A is the value consumer which requests two values
from the refering blocks. Each of blocks B and C provide
a single value on their local stack.

First request with index 0 will be satisfied by block B
because it has 1 value on the local stack.

Request with index 1 is more complex. First, block A looks
into block B because it is the only referer. But block B
have only 1 value on the stack and therefore could not
provide a value with index 1. Hence, block C is queried
recursively.

The problem is that block C also have only 1 value and
could not satisfy request with index 1.

Problem is solved by substracting the size of local stack
from the requested index on each recursion entry.

Finally, second value will be requested from block C
with effective index 1 - 1 = 0.

Issue: #32
Issue: #2
kpp added a commit that referenced this issue Jul 4, 2014
kpp added a commit that referenced this issue Jul 4, 2014
@kpp kpp modified the milestones: Version 0.5, Version 0.3 Jan 30, 2015
kpp added a commit that referenced this issue Jan 31, 2015
kpp added a commit that referenced this issue Feb 1, 2015
kpp added a commit that referenced this issue Feb 2, 2015
kpp added a commit that referenced this issue Feb 3, 2015
kpp added a commit that referenced this issue Feb 4, 2015
kpp added a commit that referenced this issue Feb 5, 2015
kpp added a commit that referenced this issue Feb 5, 2015
kpp added a commit that referenced this issue Feb 6, 2015
kpp added a commit that referenced this issue Feb 6, 2015
kpp added a commit that referenced this issue Feb 6, 2015
kpp added a commit that referenced this issue Feb 7, 2015
kpp added a commit that referenced this issue Feb 7, 2015
kpp added a commit that referenced this issue Feb 8, 2015
kpp added a commit that referenced this issue Feb 12, 2015
kpp added a commit that referenced this issue Feb 24, 2015
kpp added a commit that referenced this issue Mar 3, 2015
kpp added a commit that referenced this issue Mar 6, 2015
kpp added a commit that referenced this issue Mar 6, 2015
kpp added a commit that referenced this issue Mar 7, 2015
@0x7CFE 0x7CFE mentioned this issue Mar 18, 2015
21 tasks
kpp added a commit that referenced this issue Mar 18, 2015
@0x7CFE 0x7CFE modified the milestones: Version 0.4, Version 0.5 Mar 24, 2015
@0x7CFE 0x7CFE mentioned this issue Mar 24, 2015
20 tasks
kpp added a commit that referenced this issue Apr 11, 2015
kpp added a commit that referenced this issue Apr 12, 2015
@0x7CFE 0x7CFE closed this as completed Apr 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants