The II value is incremented before exiting the loop, and therefor when used in the optimization remarks and debug dumps it did not reflect the initiation interval actually used in Schedule.
Details
Diff Detail
Unit Tests
Event Timeline
Hi Marianne,
Thanks for the patch. Sorry that it took a while to get to this. I just have a couple of questions.
Thanks,
Brendon
llvm/lib/CodeGen/MachinePipeliner.cpp | ||
---|---|---|
2126 | Does this need to be decremented only if scheduledFound is true? Another possibility is to use Schedule.getInitiationInterval() instead of II in the subsequent debug and remark messages. |
llvm/lib/CodeGen/MachinePipeliner.cpp | ||
---|---|---|
2126 | In fact, I am not sure what is the point to print the II when the schedule is not found. But, I think it is valid to decrement all the time, since the ++ is done right before exiting the loop, no matter if the schedule is found or not. It will represent the last II that was actually tried. I thought of using a getInitiationInterval() function, but it doesn't exist. It was more simple to decrement the counter than to create a new getter function. |
llvm/lib/CodeGen/MachinePipeliner.cpp | ||
---|---|---|
2126 | You're correct - it is valid to always decrement. I still think it better to add and use a getInitiationInterval() function, and then change the scope of II so that it is limited to the loop. But, it's more important that the correct valid is printed, so either approach is an improvment. |
Updated patch with the cleaner approach of creating a getInitiationInterval() function.
Does this need to be decremented only if scheduledFound is true?
Another possibility is to use Schedule.getInitiationInterval() instead of II in the subsequent debug and remark messages.