This is the mail archive of the gcc-patches@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]

Re: Gcc 3.1 performance regressions with respect to 2.95.3


 In message <CD2AF4D9-40E6-11D6-B5E2-003065C86F94@apple.com>, Dale Johannesen 
writes:
 > I don't think the problem has anything to do with clobbers per se; it's
 > more general than that. 
Yes/No.

There is no benefit from separating CLOBBERs from a later set of the same
location.  In fact, a CLOBBERs takes no resources at all -- it's merely
there for dataflow purposes and from a scheduling standpoint it ought to
be ignored, must like we should ignore a naked USE.


 > I have half a dozen bug reports of cases where
 > the scheduler pass1 makes the code worse by introducing too many stack
 > temps.  The basic problem, IMO, is that it has no concept that increasing
 > register lifetimes too much is a bad thing.
Yes, this is a well known issue with instruction scheduling.  By it's very
nature it increases register pressure and as a result can cause spills in
code that didn't previously spill.

Fixing this is non-trivial.  If you look at literature in this space it 
tends to center around integrating the scheduler and register allocation or
in the ability to back up and reschedule hunks of code if spills occur.

While making the existing code register pressure aware is a reasonable thing
to do, it is very tricky to get it right -- too many heuristics to reduce
pressure will slow down code by inserting lots of pipeline bubbles.

There is literature on computing register pressure and reducing register
pressure.  I believe Morgan's book had a good discussion on that issue.
Those may have better performance haracteristics than twiddling the
scheduler directly to avoid increasing register pressure.

 > quick fix, and other things keep coming up.)  Perhaps it should keep
 > track of how many values are live simultaneously, and avoid increasing
 > that number.
That's step #1 -- keeping track of how many values are live at any given point
for each register class.

Step #2 is you have to query the backend to see if the pressure exceeds the
target processor's capabilities.

Step #3 is to reduce pressure as needed.  Refer to Morgan for a nice set of
heuristics to reduce register pressure.  They're actually quite nice.


 > You might be able to hack around the specific problem shown by using
 > SCHED_GROUP_P to keep the two subreg stores and the clobber together.
If y'all can figure a way to make it work, feel free.  But my experiences
with trying to use SCHED_GROUP_P to do the same thing were a miserable
failure.

jeff


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