As loads are combined and widened, we replaced their sext users operands whereas we should have been replacing the uses of the sext. I've added a load of tests, with only a few of them originally causing assertion failures, the reset improve pattern coverage.
Details
Diff Detail
Event Timeline
How did we end up with this testing gap? I haven't been closely watching what tests were committed with previous patches.
Could you have caught this earlier by using AssertingVH in more places?
If you're confident this is the right patch, we can continue discussing post-commit; I'd like to unbreak the Android bot.
lib/Target/ARM/ARMParallelDSP.cpp | ||
---|---|---|
700 | I don't understand how this makes a difference; the new SExt has to have the same operand and result type as the old one, I think, so making a new SExt followed by RAUW should be the same as changing the operand of the original. Is the old instruction in the wrong position? Or is there some sort of invalidation issue? |
Because of the VecLd[0]/LHS typo, I had assumed that there was something wrong with the handling of the 'exchange' instructions. When I added that functionality, the tests weren't very varied so I assumed that I had missed an edge case with operand orderings. What the tests show is that there are some patterns which don't get optimised well, see the TODOs. The tests in overlapping are the kind of accesses that cause the problems and it wasn't something I had thought about. We test for sext loads with multiple users, but not in the case where multiple ones are widened.
lib/Target/ARM/ARMParallelDSP.cpp | ||
---|---|---|
700 | The issue arises when a load is used to create more than one wide load. In the first instance, the sext would use the new load and the original load would have no users. In the second instance, when we enter this method, we'll hit the assertion because we try to look at the sext user of the original load. |
I don't understand how this makes a difference; the new SExt has to have the same operand and result type as the old one, I think, so making a new SExt followed by RAUW should be the same as changing the operand of the original. Is the old instruction in the wrong position? Or is there some sort of invalidation issue?