Closed IanWood1 closed 3 days ago
Actually, we don't need this. We are good on TOM vae decode. The compilation issue is with vae encode which we don't need but is part of the IR. I changed the export, so it doesn't worry about vae encode. This is also why it wasn't picked up by IREE CI. We can wait for Nirvedh's long term changes here as I think we were saying this is not the most ideal route. But, thanks for getting in a quick fix @IanWood1 :)
Actually, we don't need this. We are good on TOM vae decode. The compilation issue is with vae encode which we don't need but is part of the IR. I changed the export, so it doesn't worry about vae encode. This is also why it wasn't picked up by IREE CI. We can wait for Nirvedh's long term changes here as I think we were saying this is not the most ideal route. But, thanks for getting in a quick fix @IanWood1 :)
Ahh that makes sense. Great, I'll close this PR then.
Fixes the compilation issue in https://github.com/iree-org/iree/issues/19230 but a more nuanced solution is needed since it can sometimes be beneficial to reduce the computation done by
linalg.generic
s with reduction iterators.