Skip to content

Add support for homogenous tuples#44774

Closed
malfet wants to merge 3 commits intopytorch:masterfrom
malfet:malfet/jit-support-homogenous-tuples
Closed

Add support for homogenous tuples#44774
malfet wants to merge 3 commits intopytorch:masterfrom
malfet:malfet/jit-support-homogenous-tuples

Conversation

@malfet
Copy link
Copy Markdown
Contributor

@malfet malfet commented Sep 16, 2020

Alias homogenous tuples to lists in jit frontend parser
Homogenous tuple is defined a Tuple[Type, ...] and semantically very similar to List[Type]

This would allow one to use torch.nn.common_types._size_any_t to type annotate jit functions

@malfet malfet requested a review from suo September 16, 2020 05:16
@malfet malfet requested a review from apaszke as a code owner September 16, 2020 05:16
@facebook-github-bot facebook-github-bot added the oncall: jit Add this issue/PR to JIT oncall triage queue label Sep 16, 2020
@codecov
Copy link
Copy Markdown

codecov Bot commented Sep 16, 2020

Codecov Report

Merging #44774 into master will decrease coverage by 0.00%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #44774      +/-   ##
==========================================
- Coverage   68.10%   68.10%   -0.01%     
==========================================
  Files         393      393              
  Lines       50945    50945              
==========================================
- Hits        34698    34697       -1     
- Misses      16247    16248       +1     
Impacted Files Coverage Δ
torch/testing/_internal/expecttest.py 77.55% <0.00%> (-1.03%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e2bcdc7...deb19e7. Read the comment docs.

Copy link
Copy Markdown
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

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

Comment thread torch/csrc/jit/frontend/script_type_parser.cpp Outdated
@malfet malfet force-pushed the malfet/jit-support-homogenous-tuples branch from da89c40 to 22f9df3 Compare September 18, 2020 22:41
@dr-ci
Copy link
Copy Markdown

dr-ci Bot commented Sep 18, 2020

🔗 Helpful links

💊 CI failures summary and remediations

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


Commit deb19e7 was recently pushed. Waiting for builds...


This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.

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

Click here to manually regenerate this comment.

@malfet
Copy link
Copy Markdown
Contributor Author

malfet commented Sep 18, 2020

Update the PR, which includes #44959, #44958 and [JIT] Prohibit subscripted assignments for tuple types

Alias homogenous tuples to lists in jit frontend parser
Homogenous tuple is defined a `Tuple[Type, ...]` and semantically very similar to `List[Type]`

This would allow one to use `torch.nn.common_types._size_any_t` to type annotate jit functions
@malfet malfet force-pushed the malfet/jit-support-homogenous-tuples branch 2 times, most recently from 1a54c65 to 844f628 Compare September 24, 2020 23:22
@malfet malfet force-pushed the malfet/jit-support-homogenous-tuples branch from 844f628 to deb19e7 Compare September 24, 2020 23:39
Copy link
Copy Markdown
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

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

if (rhs_->kind() == AnyTupleType::Kind) {
return true;
}
if (rhs_->kind() == ListType::Kind) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This rule seems off. It suggests that Tuple[int, ...] <: List[Tensor].

I don't think VariableLengthTuple should subtype any kind of List. It cannot be used safely in place of a List, since List allows additional operations which VariableLengthTuple does not.

} else if(t.kind() == TypeKind::ListType) {
auto prim = t.cast<ListType>()->getElementType();
out << *prim << "[]";
} else if(t.kind() == TypeKind::VariableLengthTupleType) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

For a Tuple[int, ...] this will print as int[], which is indistinguishable from a list of ints. That may cause potential round-trip issues when serializing schemas (where a VariableLengthTuple accidentally gets casted to a List because the parser can't tell the difference). It will also confuse IRParser, which parses a IR graph string back into an actual Graph object.

We will probably need to define a way to represent a variable length tuple in the schema language as well, and use that here.

}
}

#if 0
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This part is commented out?

Comment thread test/test_jit_py3.py
# self.assertTrue(set(['aten::add.Tensor', 'aten::mul.Scalar']).issubset(
# set(torch.jit.export_opnames(scripted_M_mod))))

def test_homogeneous_tuple(self):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should have more tests here:

  1. Tests of the functionality of VariableLengthTuples, and that they actually work when you run the function and compare the results to a pure Python implementation.
  2. Tests of serialization/deserialization (use a VariableLengthTuples as an attribute to a module and make sure it still works when coming out the other side).
  3. Tests of various implicit conversion behaviors that we want to work, as well as subtyping behavior.

@github-actions
Copy link
Copy Markdown
Contributor

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.

@github-actions github-actions Bot added the Stale label Apr 12, 2022
@github-actions github-actions Bot closed this May 12, 2022
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 Stale

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants