Avoid symbolic output extent in newOutputDomain

[jacobhinkle]

Fixes #357

There are a combination of issues address by this PR. First, as noted in the issue, we should not exact map between Symbolic domains. However, there is still an issue where the output extent, computed at Fusion definition, is sometimes set equal to the symbolic extent even though that extent might concretize to 1 and then become a resolved broadcast. In those cases we should either use any Iteration extents if available, or if we have an unambiguous Symbolic extent, we can use it.

[jacobhinkle]

I've encountered an interesting limitation. For a dynamic resize resulting in a broadcast, we may have a concretized root domain of type Iteration that's resized to a Broadcast rfactor domain. For example, as of now the example in #357 concretizes (properly?) to

Inputs:
  T0_g[ iS0{i0}, iS1{i2} ], float
  T1_g[ iS2{i3}, iS3{i4} ], float
  i5, int64_t
  i6, int64_t
Outputs:
  T3_g[ iS8{i3}, iS9{i4} ], float
  T2_g[ bS10{( i0 + i5 )}rf, iS11{( i2 + i6 )}rf ], float

%kernel_math {
T2_g[ bS10{( i0 + i5 )}rf, iS11{( i2 + i6 )}rf ]
   = pad( T0_g[ iS0{i0}, iS1{i2} ], {0, i5, 0, i6} )
T3_g[ iS8{i3}, iS9{i4} ]
   = T2_g[ bS10{( i0 + i5 )}rf, iS11{( i2 + i6 )}rf ]
   * T1_g[ iS2{i3}, iS3{i4} ];

This currently fails when building ComputeAtMap while building the structure used to define concrete IDs, ConcretizedBroadcastDomains at this check: https://github.com/NVIDIA/Fuser/blob/main/csrc/device_lower/analysis/trivial_broadcast.cpp#L99. I believe this assumes that a broadcast will come from a BroadcastOp, and tries to map every Broadcast root ID to its "original" root ID, meaning the ID in the root of the input to a BroadcastOp. In the case of Resize we don't have a separate TV op representing the broadcast, so to satisfy this assumption we would need to insert an op at concretization to separately broadcast after concretizing all resized IterDomains as Iteration. That's a bit invasive, so I'm checking to see if in this case it might be safe to use the resize itself as the concrete ID.

[jacobhinkle]

Note that reshape does not trigger this error because during concretization/static reshape, broadcasts are detected and actual broadcast ops are inserted. This may be the way to go; I can detect broadcast output domains that come from Resize op while processing a TV and ideally remove them then insert the broadcast on that TV. I'm not exactly sure how best to remove that ID without it being a Broadcast. One option is to Merge that ID with its neighbor assuming it has any. I will continue thinking about this.

[naoyam]

It seems to me that the problem lies in ConcretizedBroadcastDomains. If we extend it to handle broadcast IDs produced by IterDomain expressions, should the problem be fixed?

[jacobhinkle]

If we extend it to handle broadcast IDs produced by IterDomain expressions, should the problem be fixed?

I believe so.

[naoyam]

OK, then I think that would be preferred over adding broadcast ops. Let me know if you need any help.

[jacobhinkle]

This is being addressed in #420