https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
--- Comment #8 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- Even this test case isn't truly horrible for real-world code (it looks nastier than it is, as stack stores tend to have minimal real cost). This is an issue only on "older" processors; it's just that a lot of those older processors, particularly POWER7, are still in use. With POWER8 and later, direct moves between GPR and FPR register files make this worthwhile. I don't know that we need to do anything to fix this right now, other than to try to find some other way to test what this test case is trying to verify (the new code made this impossible). Is your change done at all opt levels? I'm not sure whether this test would work at lower opt, anyway. The test is verifying that we force some nops in between a store and load when we know they alias, to mitigate the cost of the stall while the load tries to get the data out of the store queue. The extra code here gets in the way of that, solving the problem another way. Pat, any thoughts on whether the test can be rewritten some other way to force the nop insertion? Long term, having a way to ask the back end if a particular subreg is a good or bad idea seems useful, as this probably comes up in a number of contexts. I don't have any stellar ideas about how to do that yet (other than Yet Another Target Hook Not Everyone Implements). It doesn't fit in our usual cost-model query structure.