This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] third liveness pass
- From: Jan Hubicka <jh at suse dot cz>
- To: law at redhat dot com
- Cc: Jan Hubicka <jh at suse dot cz>, Richard Henderson <rth at redhat dot com>,gcc at gcc dot gnu dot org, gcc-pdo at atrey dot karlin dot mff dot cuni dot cz,gcc-patches at gcc dot gnu dot org
- Date: Tue, 28 May 2002 11:04:07 +0200
- Subject: Re: [RFC] third liveness pass
- References: <20020527120043.GB8249@atrey.karlin.mff.cuni.cz> <22647.1022511676@porcupine.cygnus.com>
> > Would be OK to make patch that moves PROP_SCAN_DEAD_STORES out of
> > PROP_FINAL and makes the PROP_FINAL pass to include it conditionally? I
> > still guess we can include dead code removal as it pays back by avoiding
> > reload/global to work too hard.
> Seems reasonable.
>
> Another idea for doing DSE in a much cleaner, potentially less expensive
> way would be to look at dependency information.
>
> Look at the dependencies generated when scheduling if we find that a store Y
> is a direct descendant of store X in the dependency tree and X and Y are the
> same memory location, then Y _may_ be a dead store.
>
> The problem boils down to determining if there is some valid schedule which
> could result in X firing resolving the final dependency for Y. If there is
> such a schedule, then Y is a dead store.
>
> So this means that we'd need to prove that none of other descendants of X
> reach Y in the dependency tree -- and do so in a reasonable amount of
> computation.
>
> So conceptually you could hook in a memory optimizer to run immediately
> after we build the dependency graph for scheduling.
>
> Alternately you can hook right into the scheduler code and detect some of these
> as we actually resolve dependencies -- it's fast, but less clean and may
> miss some redundant memory operations.
>
> These schemes may or may not be less expensive than the DSE code currently
> in flow.c, but it might be worth an investigation.
Yes, I was playing with this idea as well. It would be nice to break
out the dependency graph generation out of scheduler, as for instance
reg-stack can use it as well, but unforutnately I am not sure I can do
this at the moment, but I will keep it in the mind.
Honza
>
> jeff
>