[Passes] Remove LoopInterchange from O1 pipeline #145071
Conversation
This is a fairly exotic pass, I don't think it makes a lot of sense to run it at O1, esp. as vectorization wouldn't run at O1 anyway.
Good question. Do we expect that loop interchange helps other simplifications in some way? If not, it's probably better to make it part of the optimization pipeline. IIRC there was a patch that added versioning support to DA, and in that case we'd definitely don't want it in the simplification pipeline. |
|
By default, That is, the following transformations could occur: // Original code
for (int j = 0; j < m; j++)
for (int i = 0; i < n; i++)
a[i][j] = b[i][j];
// LoopInterchange
for (int i = 0; i < n; i++)
for (int j = 0; j < m; j++)
a[i][j] = b[i][j];
// LoopIdiomRecognize
for (int i = 0; i < n; i++)
memcpy(a[i], b[i], m * sizeof(a[i][0]));However, this is just a possibility. I don't have a strong motivation to enhance other simplifications via loop interchange, and I don't know if others have added this pass for simplifications.
Maybe #123436 ? At the moment, DA only has the functionality to collect assumptions and versioning hasn't been implemented yet (though I assume it's something they intend to add in the future). IMHO, if it is allowed (e.g., low impact on compile time), it would be ideal to keep LoopInterchange in the simplification pipeline for data locality (while suppressing some features like versioning), and then add another instance in the optimization pipeline for vectorization. |
This is a fairly exotic pass, I don't think it makes a lot of sense to run it at O1, esp. as vectorization wouldn't run at O1 anyway.
This is a fairly exotic pass, I don't think it makes a lot of sense to run it at O1, esp. as vectorization wouldn't run at O1 anyway.
As mentioned in llvm#145071, LoopInterchange should be part of the optimization pipeline rather than the simplification pipeline. This patch moves LoopInterchange into the optimization pipeline. More contexts: - By default, LoopInterchange attempts to improve data locality, however, it also takes vectorization opportunities into account. Given that, it is reasonable to run it as close to vectorization as possible. - I looked into previous changes related to the placement of LoopInterchange, but couldn’t find any strong motivation suggesting that it benefits other simplifications. - As far as I tried some tests (including llvm-test-suite), removing LoopInterchange from the simplification pipeline does not affect other simplifications. Therefore, there doesn't seem to be much value in keeping it there.
As mentioned in llvm#145071, LoopInterchange should be part of the optimization pipeline rather than the simplification pipeline. This patch moves LoopInterchange into the optimization pipeline. More contexts: - By default, LoopInterchange attempts to improve data locality, however, it also takes vectorization opportunities into account. Given that, it is reasonable to run it as close to vectorization as possible. - I looked into previous changes related to the placement of LoopInterchange, but couldn’t find any strong motivation suggesting that it benefits other simplifications. - As far as I tried some tests (including llvm-test-suite), removing LoopInterchange from the simplification pipeline does not affect other simplifications. Therefore, there doesn't seem to be much value in keeping it there.
This is a fairly exotic pass, I don't think it makes a lot of sense to run it at O1, esp. as vectorization wouldn't run at O1 anyway.