Skip to content

Conversation

@davidberard98
Copy link
Contributor

@davidberard98 davidberard98 commented Mar 26, 2022

Stack from ghstack:

aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

Differential Revision: D35188927

aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

[ghstack-poisoned]
@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Mar 26, 2022

🔗 Helpful links

💊 CI failures summary and remediations

As of commit 184f81d (more details on the Dr. CI page):


💚 💚 Looks good so far! There are no failures yet. 💚 💚


This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

@facebook-github-bot facebook-github-bot added the oncall: jit Add this issue/PR to JIT oncall triage queue label Mar 26, 2022
davidberard98 added a commit that referenced this pull request Mar 26, 2022
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

ghstack-source-id: 665c6c0
Pull Request resolved: #74794
@davidberard98 davidberard98 linked an issue Mar 26, 2022 that may be closed by this pull request
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

[ghstack-poisoned]
davidberard98 added a commit that referenced this pull request Mar 26, 2022
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

ghstack-source-id: 7e5e3eb
Pull Request resolved: #74794
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

[ghstack-poisoned]
davidberard98 added a commit that referenced this pull request Mar 28, 2022
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

ghstack-source-id: 73ed41a
Pull Request resolved: #74794
@davidberard98
Copy link
Contributor Author

@davidberard98 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@davidberard98 davidberard98 requested review from Gamrix and eellison and removed request for Gamrix and eellison March 28, 2022 20:13
@davidberard98
Copy link
Contributor Author

Turns out previous fix is insufficient, here's a new repro that still fails

import torch
from typing import Dict

def fn(x, y, cond: bool, d: Dict[str, torch.Tensor]):
    if cond:
        m = x.relu()
        f1 = torch.rand((2, 2))
        d["test"] = f1
        z = d["test"]
    else:
        m = y.gelu()
        f2 = torch.rand((3, 2))
        d["test"] = f2
        z = d["test"]
    return m, z

fn_s = torch.jit.script(fn)
x = torch.rand((2, 2))
y = torch.rand((2, 2))
d = {"x": x}
fn_s(x, y, 1, d)

@Gamrix Gamrix self-requested a review March 28, 2022 21:38
@Gamrix
Copy link
Contributor

Gamrix commented Mar 28, 2022

The fix looks good, though yes, the new repro is still failing.

@Gamrix
Copy link
Contributor

Gamrix commented Mar 28, 2022

From your repo, aten::_set_item is somehow not being treated as aliasing aten::__getitem__, and hence the latter is being pulled out of the if statement. Do we have the AliasDB signature for aten::_set_item ?

[DUMP common_expression_hoisting.cpp:148] After CEH Changes
[DUMP common_expression_hoisting.cpp:148] graph(%x.1 : Tensor,
[DUMP common_expression_hoisting.cpp:148]       %y.1 : Tensor,
[DUMP common_expression_hoisting.cpp:148]       %cond.1 : bool,
[DUMP common_expression_hoisting.cpp:148]       %d.1 : Dict(str, Tensor)):
[DUMP common_expression_hoisting.cpp:148]   %6 : NoneType = prim::Constant()
[DUMP common_expression_hoisting.cpp:148]   %7 : str = prim::Constant[value="test"]() # misc/ceh_bug_repro.py:9:10
[DUMP common_expression_hoisting.cpp:148]   %8 : str = prim::Constant[value="none"]()
[DUMP common_expression_hoisting.cpp:148]   %z.3 : Tensor = aten::__getitem__(%d.1, %7) # misc/ceh_bug_repro.py:15:12
[DUMP common_expression_hoisting.cpp:148]   %m : Tensor = prim::If(%cond.1) # misc/ceh_bug_repro.py:6:4
[DUMP common_expression_hoisting.cpp:148]     block0():
[DUMP common_expression_hoisting.cpp:148]       %m.1 : Tensor = aten::relu(%x.1) # misc/ceh_bug_repro.py:7:12
[DUMP common_expression_hoisting.cpp:148]       %20 : int[] = prim::Constant[value=[2, 2]]()
[DUMP common_expression_hoisting.cpp:148]       %f1.1 : Tensor = aten::rand(%20, %6, %6, %6, %6) # misc/ceh_bug_repro.py:8:13
[DUMP common_expression_hoisting.cpp:148]        = aten::_set_item(%d.1, %7, %f1.1) # misc/ceh_bug_repro.py:9:8
[DUMP common_expression_hoisting.cpp:148]       -> (%m.1)
[DUMP common_expression_hoisting.cpp:148]     block1():
[DUMP common_expression_hoisting.cpp:148]       %m.3 : Tensor = aten::gelu(%y.1, %8) # misc/ceh_bug_repro.py:12:12
[DUMP common_expression_hoisting.cpp:148]       %21 : int[] = prim::Constant[value=[3, 2]]()
[DUMP common_expression_hoisting.cpp:148]       %f2.1 : Tensor = aten::rand(%21, %6, %6, %6, %6) # misc/ceh_bug_repro.py:13:13
[DUMP common_expression_hoisting.cpp:148]        = aten::_set_item(%d.1, %7, %f2.1) # misc/ceh_bug_repro.py:14:8
[DUMP common_expression_hoisting.cpp:148]       -> (%m.3)
[DUMP common_expression_hoisting.cpp:148]   %19 : (Tensor, Tensor) = prim::TupleConstruct(%m, %z.3)
[DUMP common_expression_hoisting.cpp:148]   return (%19)

aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

Differential Revision: [D35188927](https://our.internmc.facebook.com/intern/diff/D35188927)

[ghstack-poisoned]
davidberard98 added a commit that referenced this pull request Mar 28, 2022
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

ghstack-source-id: b8f9b50
Pull Request resolved: #74794
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

Differential Revision: [D35188927](https://our.internmc.facebook.com/intern/diff/D35188927)

[ghstack-poisoned]
@davidberard98
Copy link
Contributor Author

@Gamrix couldMoveBeforeTopologicallyValid returns true if it's possible to move the specified node and some "working set" to before the target node

In the case of the 2nd repro, we try to move the getitem node. It's possible to move this all before the first node as long as we include the set_item node in the working set, so couldMoveBeforeTopologicallyValid returns true.

So then we were moving getitem outside of the if block, even if we require setattr to appear before it.

aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

Differential Revision: [D35188927](https://our.internmc.facebook.com/intern/diff/D35188927)

[ghstack-poisoned]
davidberard98 added a commit that referenced this pull request Mar 28, 2022
aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

ghstack-source-id: af50b48
Pull Request resolved: #74794
// node. If it ended up at the very beginning of the if block, then it's
// safe to move it outside.
if (true_b_node != true_block->nodes().front() ||
false_b_node != false_block->nodes().front()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not safe, as you can have two separate lines of code that both can be moved forward, but not be at the front. This in turn can cause the program to loop infinitely due to the iteration order of the for loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would the loop happen?
If we have nodes n_1, n_2, ..., n_i, n_{i+1}, ..., n_m and start the loop at n_i:

  1. store n_i as false_b_node increment iterator to n_{i+1}
  2. possibly scramble n_1, n_2, ... n_i (working set can only contain nodes in between toMove node and target node)
  3. repeat

Copy link
Contributor Author

@davidberard98 davidberard98 Mar 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's guaranteed that n_{i+1}, ... , n_m are unaffected by this comment

// Move `n` (already in the graph) after `movePoint` in the topological order.
//
// Tries to preserve value dependencies, so other nodes might be moved. We
// make two guarantees about the postcondition of the node list:
// - `n` is directly after `movePoint`.
// - only nodes between `n` and `movePoint` have been moved.
//
// Returns `false` if it's impossible to move `n` after `MovePoint` without
// violating dependencies, otherwise executes the move and returns `true`

Copy link
Contributor

@Gamrix Gamrix Mar 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I forgot that we already incremented the iterator before we did all the moves. You'd think I would know my own code :/ .

@davidberard98
Copy link
Contributor Author

@davidberard98 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@davidberard98
Copy link
Contributor Author

@davidberard98 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

facebook-github-bot pushed a commit that referenced this pull request Mar 30, 2022
Summary:
Pull Request resolved: #74794

aliasdb check was incorrect, caused issues in #74056

This checks whether it is safe to move before the node at the beginning
of the if branch instead of after the node at the beginning of the if
branch

Test Plan: Imported from OSS

Reviewed By: Gamrix

Differential Revision: D35188927

Pulled By: davidberard98

fbshipit-source-id: 722ecf67840a066dbee55b4033c35122a20f368e
@facebook-github-bot facebook-github-bot deleted the gh/davidberard98/79/head branch April 3, 2022 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla signed oncall: jit Add this issue/PR to JIT oncall triage queue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

REGR: Accessing dict in JITed code in 1.11

4 participants