https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #12 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- It's not clear yet what we should do with this. It looks like SMS is able to figure out that the sign-extension is not needed in the pre-r247885 code, but can't sort this out with the IVOPTS change. The IVOPTS change looks perfectly reasonable, but has the side effect of adding a second loop-carried dependency on i_5. It could be that this is why SMS fails, but why is this worse than the previous code, which instead had two loop-carried dependencies on ivtmp.10_18? One clue is that the "before" code contains: r174:SI = (SI)r164 + 32 r164:DI = zext(r174) which is a self-contained loop-carried dependence. For the "after" code, this disappears, and instead we introduce r165:SI = (SI)r160 << 3 r166:DI = zext(r165) Here we don't have a self-contained LCD, but it introduces confusion into an existing LCD that occurs later: r169:SI = (SI)r160 + 4 r160:DI = sext(r169) The latter is the sign-extension that we aren't able to remove. I suspect that the extra interference of the new code is the reason. It looks like the cost leading to the IVOPTS change is probably very close to the cost of leaving things as they were. Is that right? Is it possible for IVOPTS to detect that it's going to complicate a simple LCD in a case where the cost model doesn't show much difference? Not sure that is the right approach, just wondering. I will dig into the SMS algorithm next time I get some free time to look at it, and try to confirm my guesses. Maybe it can be taught to deal with this case.
