This is the mail archive of the
mailing list for the GCC project.
Re: [rtlopt] Store motion rewrite
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org,Andreas Jaeger <aj at suse dot de>, Jan Hubicka <jh at suse dot cz>,Jeffrey Law <law at redhat dot com>
- Date: Sun, 16 Feb 2003 17:40:30 +0100
- Subject: Re: [rtlopt] Store motion rewrite
- References: <200302140138.UAA21996@makai.watson.ibm.com> <Pine.LNX.email@example.com>
> > Zdenek> from first glance it seems almost same in functionality and faster; why it
> > Zdenek> is not in mainline yet?
> > Let's try to merge the best features of both versions, make sure
> > it works correctly, and submit it for inclusion in the trunk.
> Zdenek, I assume you've bootstrapped/regtested this before putting it on
> the rtlopt-branch?
> If so, it should be pretty easy to apply the speedup.
> IIRC, the real killer is computing the kill and transparent table, because
> we end up calling store_ops_ok a billion times.
This is interesting, I assumed that store_killed_in_insn that we must
call for (almost) every insn is the bottleneck.
> Once that is done, if you have answers already for all the regs in the
> current store, you can just OR them together, and you get the answer for
> the current store.
> IE if we know that
> stores with reg 12 are killed only in bb 6, 9, 12 because of reg 12
> stores with reg 13 are killed only in bb 1, 3, 5 because of reg 13
> Then given a store using both reg 12 and 13, we know the answer is 1,
> 3, 5, 6, 9, 12 without calling store_ops_okay at all.
yes, it seems quite easy to do; I will add it once I catch the bugs in my
rewrite (currently it bootstraps on athlon, but misscompiles vortex and
somehow manages to noticeably slow down eon in spec2000).