Skip trivial Resize, handle resize of Broadcast at concretization.

[jacobhinkle]

This updates the root to rfactor propagation in IterType concretization of dynamic fusions.

Previously, although we only overwrote Symbolic IterDomains in this step, we still asserted that we could infer an IterType for each I moved that check so that it is only applied when we need to make a change.

Additionally, we previously propagated Broadcast-only IterDomains as Symbolic, since we combine with our previous estimate using promoteIterType. As mentioned in a comment, this means Broadcast gets propagated as Symbolic. Instead we now only fall back to promoteIterType when there are multiple input IterTypes to the IterDomain expression.

Fixes #798

[jacobhinkle]

!build

[naoyam]

It seems odd to check the trivial case here as this part is to figure out the iteration type. Why not just do this check early? Also, maybe we should check the optional iteration type is not given or the same as the input iteration type.

[jacobhinkle]

Good point. I moved the check to the beginning of the function and added an assertion that the specified IterType does not clash, if it is given.

[naoyam]

Here, updated_id->getIterType() should be always non symbolic, right?

[naoyam]

This feels more intuitive to me.

for (const auto i: c10::irange(...)) {
    auto updated_id = ...;
  TORCH_INTERNAL_ASSERT(updated_id->getIterType() != IterType::Symbolic);
  if (i == 0) {
    iter_type = updated_id->getIterType();
  } else {
    iter_type = ops::promoteIterType(iter_type, updated_id->getIterType());
  }
}

[jacobhinkle]

Here, updated_id->getIterType() should be always non symbolic, right?

I think it could still be symbolic, since updated_id could have been mutated because its extent was mutated, without setting the IterType yet.

[naoyam]

Could you give me an example?

[jacobhinkle]

Actually I think you might be right that this won't happen.

We currently replace derived extents when we concretize reshape using registerMutation. So if a downstream TensorView has the old extent then the default mutate will create a new Symbolic ID with the new extent here https://github.com/NVIDIA/Fuser/blob/main/csrc/dynamic_transform.cpp#L570 .
For example:

T1[ ?S2{div(i0, s0)}, ?S3{s0} ] = reshape(T0[ div(i0, s0), s0 ]);
T2[ ?S4{div(i0, s0)}, ?S5{s0} ] = neg(T1);

Then depending on the inputs we might concretize this as

T1[ iS6{ceilDiv(i0, 3)}, iS7{3} ] = reshape(T0[ div(i0, s0), s0 ]);
T2[ iS10{ceilDiv(i0, 3)}, iS11{3} ] = neg(T1);

When mutate is called for T2, first div(i0, s0) will be recognized as mutated, so ?S4{div(i0, s0)} will be mutated as ?S10{ceilDiv(i0, 3)}, then later in the mutate we will set its IterType in propagateFromProducerToConsumer.

This happens for root domains of T2, but anything downstream of root up until rfactor should not be mutated yet, unless it was a Resize output, in which case the IterType should've been set before this traversal. I switched to the indexed loop as you suggested. I'll add this check for Symbolic iter type as well. Thanks!

[naoyam]

The changes make sense to me. Just left some suggestions. Feel free to merge.

[naoyam]

LGTM. Thanks for the update!