Add support for returning more than one copy of the same tensor

[ramiro050]

One of the simplifications made by the pass RefinePublicReturn
currently only happens if the tensor in question only has one
user. However, the current method of checking this does not correctly
handle the case of a user having multiple uses of the same
tensor. This commit makes sure only unique users are considered.

[silvasean]

Fascinating. I always though that getUsers was deduped.

[silvasean]

Did you actually run into this in a real test? I would have thought that by construction in our pipeline we wouldn't hit this situation of multiple uses. If that's the case, then we can change it to a check that there is only one use.

[ramiro050]

Fascinating. I always though that getUsers was deduped.

Yeah, I thought it was weird too.

Did you actually run into this in a real test? I would have thought that by construction in our pipeline we wouldn't hit this situation of multiple uses. If that's the case, then we can change it to a check that there is only one use.

I ran into this while running the unit tests I had written for my torchdynamo compiler. It is definitely something that can be modified to not return two copies of the same tensor. In real world applications, I imagine this case is not common.

I would have thought that by construction in our pipeline we wouldn't hit this situation of multiple uses

What aspects of the pipeline would guarantee this?

[silvasean]

Did you actually run into this in a real test? I would have thought that by construction in our pipeline we wouldn't hit this situation of multiple uses. If that's the case, then we can change it to a check that there is only one use.

I ran into this while running the unit tests I had written for my torchdynamo compiler. It is definitely something that can be modified to not return two copies of the same tensor. In real world applications, I imagine this case is not common.

Okay, that is real enough. Let's land this.

I would have thought that by construction in our pipeline we wouldn't hit this situation of multiple uses

What aspects of the pipeline would guarantee this?

I was thinking that something could end up inserting one copy per operand of the return op which would guarantee that the return op always had distinct values. But I guess that isn't the case here since you hit it from "user code".