This is the mail archive of the 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: [rtlopt] Store motion rewrite


> > 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.
> >
> Sure.
> 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).


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