-
Notifications
You must be signed in to change notification settings - Fork 26.3k
[jit] make containedElements a vector #21445
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
Conversation
The bitset doesn't preserve ordering, which will be important for doing contained element analysis on tuples/classes. One annoying thing: If we have a tuple like `(Tensor, int, Tensor)`, we want the contained elements to match, so that indexing into `type->containedTypes()` is the same as indexing into `el->containedElements()`. But since `int` is not mutable, we need to make the vector `(Element*, nullptr, Element*)`. Open to suggestions how to avoid.
| // | ||
| // NOTE: elements MAY BE nullptr; this represents that they are non-aliasing | ||
| // types. | ||
| std::vector<Element*> containedElements; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we really want to maintain the indexing, we need a set per index.
otherwise with something like:
if cond:
y = (tensor, tensor)
else:
y = (tensor, tensor)
the output of the if node needs a different set per index. as is, we're just appending, and it has a vector of length 4
|
Going to close this since currently tracking aliasing into tuples is impossible anyway (since TupleIndex is dynamic) |
Couldn't you make the make the Index point to the correct element if the index is constant, otherwise point to the tuple (or all the elements in the tuple) ? |
|
Pointing elements to different categories of things (contained type vs. container type) based on a property of the graph is not maintainable imo. We need things to behave consistently, esp. since alias analysis is annoyingly complicated already. |
|
that makes sense. but you could point it to all elements of the tuple, which are guaranteed to all be the same type. |
Stack from ghstack:
The bitset doesn't preserve ordering, which will be important for doing
contained element analysis on tuples/classes.
One annoying thing: If we have a tuple like
(Tensor, int, Tensor), wewant the contained elements to match, so that indexing into
type->containedTypes()is the same as indexing intoel->containedElements(). But sinceintis not mutable, we need tomake the vector
(Element*, nullptr, Element*). Open to suggestions howto avoid.