[NNC] Some ops have type promotion logic which adds extra casts & does compute in different dtype than eager

[eellison]

🐛 Bug

Many NNC type promotion goes through a common path which promotes inputs according to the highest input type, and then after compute, casts the output to whichever output type was recorded when the op was run in eager.

Because we have the output type specified, all NNC ops will give the correct dtype. However, the compute may be done in a different dtype than eager, and there may be extraneous casts added.

In the (worst) case of something like,

x = torch.ones([4,  4], dtype=torch.int16)
torch.addcmul(x, x, x, value=1)

We will cast all three tensor inputs to int32, do the addcmul, then cast the operation back. As opposed to eager, which will just cast value=1 to int16.

The advantage of the current approach is that we are guaranteed to have the same output dtype. I think ops could gradually be migrated over to have the correct casting behavior.

Most ops do promote to the highest dtype, so this isn't that big of an issue, but it does come up.

TODO:

• torch.addcmul (add your name here to claim)

To Reproduce

1. Comment out the output type casting of the various comput{number}Operands

2. Run python test/test_jit_fuser_te..py

[eellison]

Adding bootcamp here because each individual op is pretty easy to migrate over to the right casting logic. Starting with addcmul but we can add others.