IdModel: Loop promotion analysis step 2

[naoyam]

This is Step 2 of the loop promotion analysis. The main routines are:

• propagatePromotionsInIELGraph
• addReplayAs

[naoyam]

!build

[naoyam]

!build

[zasdfgbnm]

Finished reading the major part of this PR. Have not read any test yet. Don't see any blocker so far. I remembered you mentioned that after this step, the uninlined ID's promotion is still not correct. Could you remind me why this is the case? For example, if my fusion is

    b                I1
  /   \      -->    /  \
128 | 1/128       128 I1/128

Then after step 1, I will have b->I1, but won't step 2 just give me 128->128 and 1/128 -> I1/128, which is already correct?

[zasdfgbnm]

Finished reading tests. Looks good to me. No blocking issues in this PR. But I have another question:

Consider that I have another fusion:

I0 b       b      I1             I0 I2     I3      I1
|   \     /       |              |   \     /       |
|      b          |              |    I2*I3        |
|   /     \       |     ---->    |   /     \       |
| b{128} b{1/128} |              | 128  I2*I3/128  |
| /         \     |              | /         \     |
I0*128   (1/128) * I1            I0*128 (I2*I3/128) * I1

IIUC, we will promote (1/128) * I1 -> (I2*I3/128) * I1. But for this case, does it make sense to just not promote (1/128) * I1?

[naoyam]

Finished reading the major part of this PR. Have not read any test yet. Don't see any blocker so far. I remembered you mentioned that after this step, the uninlined ID's promotion is still not correct. Could you remind me why this is the case? For example, if my fusion is

    b                I1
  /   \      -->    /  \
128 | 1/128       128 I1/128

Then after step 1, I will have b->I1, but won't step 2 just give me 128->128 and 1/128 -> I1/128, which is already correct?

Does this answer your question?

https://docs.google.com/document/d/1y1ihF9R2kLfoMTJrqVvPVCsJCeMCNchz8WcSrqHAR_Q/edit#bookmark=id.jd2i8budl1do

[naoyam]

Finished reading tests. Looks good to me. No blocking issues in this PR. But I have another question:

Consider that I have another fusion:

I0 b       b      I1             I0 I2     I3      I1
|   \     /       |              |   \     /       |
|      b          |              |    I2*I3        |
|   /     \       |     ---->    |   /     \       |
| b{128} b{1/128} |              | 128  I2*I3/128  |
| /         \     |              | /         \     |
I0*128   (1/128) * I1            I0*128 (I2*I3/128) * I1

IIUC, we will promote (1/128) * I1 -> (I2*I3/128) * I1. But for this case, does it make sense to just not promote (1/128) * I1?

This is a very good point. I assume the CA position is 1. You're right that then the inner domain of the broadcast tensor would be promoted, but that shouldn't be necessary.

I think that the promotion is necessary only if a broadcast domain is merged with a non-broadcast domain. If it's not merged or just merged with another broadcast domain, it would remain to be a broadcast domain, so nothing to index. Even when it's merged with a non-broadcast domain but if the merge is outside of loop mapped domains, like the case above, that doesn't seem to require promotion.

For example:

   b0
 /    \
b1   b2

   i3
 /    \
i4   i5

And assume they are inlined at position 1. b2 will be promoted to i5, but that isn't necessary. In this case since b2 is still a broadcast domain, it'd be easy to ignore the promotion. We could just ignore promotion of broadcast domains. That's not the case with the example above as the promoted domain is no longer a broadcast domain, so we should probably need to do something more. I think we can avoid the promotion of such domains. I'll create an issue.

[naoyam]

!build

[naoyam]

!build

[zasdfgbnm]

Does this answer your question?

https://docs.google.com/document/d/1y1ihF9R2kLfoMTJrqVvPVCsJCeMCNchz8WcSrqHAR_Q/edit#bookmark=id.jd2i8budl1do

I need to read the step 3 PR to fully understand this piece of doc, but yes, I think this answers exactly what I asked.

Another question: does this only happen when there are new broadcasts in the fusion? If all the broadcasts are already in fusion input, will the result of step 2 be just correct?

I am wondering, assume that one day we decide to fix #1759, and assume that we decide to kill forwarding by inserting dummy broadcasting IDs all the way to inputs. Then as a side thing, will we just remove step 3-5?

[naoyam]

Does this answer your question?
https://docs.google.com/document/d/1y1ihF9R2kLfoMTJrqVvPVCsJCeMCNchz8WcSrqHAR_Q/edit#bookmark=id.jd2i8budl1do

I need to read the step 3 PR to fully understand this piece of doc, but yes, I think this answers exactly what I asked.

Another question: does this only happen when there are new broadcasts in the fusion? If all the broadcasts are already in fusion input, will the result of step 2 be just correct?

This is I'm not sure yet.

I am wondering, assume that one day we decide to fix #1759, and assume that we decide to kill forwarding by inserting dummy broadcasting IDs all the way to inputs. Then as a side thing, will we just remove step 3-5?

Maybe? Honestly I'm not sure. To be more precise, step 3 will still be necessary, which just projects back to loop groups. Steps 4 and 5 repeat steps 2 and 3, and they may not be necessary.

[naoyam]

!build