------- Additional Comments From law at redhat dot com 2005-08-17 19:31 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Wed, 2005-08-17 at 08:03 +0000, bonzini at gcc dot gnu dot org wrote:
> ------- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17
> 08:03 -------
> This small testcase is a typical case of the optimizations that CSE path
> following catches on PowerPC:
>
> unsigned outcnt;
> extern void flush_outbuf(void);
>
> void
> bi_windup(unsigned char *outbuf, unsigned char bi_buf)
> {
> outbuf[outcnt] = bi_buf;
> if (outcnt == 16384)
> flush_outbuf();
> outbuf[outcnt] = bi_buf;
> }
>
> Loading outcnt takes *three* insns: one to load the high part of the address,
> one to load the low part, one to load from memory. CSE reduces them to two by
> combining the loading of the low part with the load from memory. With CSE
> path
> following, in addition, CSE is able to factor the loads of the high part of
> the
> address, and do just one of them.
>
> Now here comes GCSE. If CSE path following is on, GCSE sees that the third
> occurrence of outcnt is the same as the second, and eliminates it. If it is
> off, GCSE is wasted to factor the loading of the address high parts.
>
> So, if we remove a pseudo-global cse pass by disabling path following, it
> would
> make sense to bump the default max-gcse-passes to 2.
Presumably the store into outbuf prevents the SSA optimizers from
commonizing the first two loads of outcnt and the call to flush_outbuf
prevents the SSA optimizers from commonizing the last load of outcnt on
the path which bypasses the call to flush_outbuf. Right?
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
