Gcc 3.1 performance regressions with respect to 2.95.3

[Dale Johannesen]

On Monday, March 25, 2002, at 09:01 PM, David Edelsohn wrote:
> 	Are you suggesting that the instructions whose dependency is
> satisfied by the clobber should be issued as soon as possible or as late
> as possible?  The problem is that not all of the dependent instructions
> have their final dependency resolved by the clobber and not all of the
> instructions can move forward outside their bb.  Whether the next,
> dependent SET comes right after the CLOBBER or much later, the lifetime of
> the pseudo still is very long because the rest of the computation
> involving the pseudo does not complete for a very long time.
> 	I think what we want is for the clobbers to be retarded as much as
> possible and to issue as many as necessary on "no-unit" in the cycle
> preceding the first SET of that REG.

I don't think the problem has anything to do with clobbers per se; it's
more general than that.  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.  (And this is something I
intend to work on, but I've looked at it enough to conclude there's no
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.

> 	The LIBCALLs I have examined look like:
>
> (clobber (reg:DI X)) [LIBCALL]
> (set (subreg:SI (reg:DI X) 0) (CONST))
> (set (subreg:SI (reg:DI X) 4) (reg:SI Y))
> (set (reg:DI X) (reg:DI X)) [RETVAL]
> (set ... (reg:DI X))

I don't see why there needs to be a clobber here at all.  Wouldn't you
have the same problem without it?  Also, as I read the subreg docs,
there should be a strict_low_part around at least the store
into (subreg 4).

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.