This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]