Skip to content

Conversation

@suo
Copy link
Member

@suo suo commented Jun 6, 2019

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), 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.

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;
Copy link
Contributor

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

@suo
Copy link
Member Author

suo commented Jun 7, 2019

Going to close this since currently tracking aliasing into tuples is impossible anyway (since TupleIndex is dynamic)

@suo suo closed this Jun 7, 2019
@eellison
Copy link
Contributor

eellison commented Jun 7, 2019

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) ?

@suo
Copy link
Member Author

suo commented Jun 7, 2019

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.

@eellison
Copy link
Contributor

eellison commented Jun 7, 2019

that makes sense. but you could point it to all elements of the tuple, which are guaranteed to all be the same type.

@facebook-github-bot facebook-github-bot deleted the gh/suo/54/head branch October 28, 2019 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module: cpp Related to C++ API oncall: jit Add this issue/PR to JIT oncall triage queue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants