------- Additional Comments From law at redhat dot com 2005-03-06 05:59 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Sat, 2005-03-05 at 10:39 +0000, stevenb at suse dot de wrote:
> ------- Additional Comments From stevenb at suse dot de 2005-03-05 10:39
> -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> > Am I missing something here? I guess I'm not sure what point you're
> > trying to make.
>
> It just seems that we could do better on initial RTL generation, e.g.
>
> ;; j = k * -1
> (insn 23 21 0 (parallel [
> (set (reg/v:DI 64 [ j ])
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff])))
> (clobber (reg:CC 17 flags))
> ]) -1 (nil)
> (nil))
>
> which we later simplify in CSE:
>
> Working on insn:
> (insn 23 21 24 0 (parallel [
> (set (reg/v:DI 64 [ j ])
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff])))
> (clobber (reg:CC 17 flags))
> ]) 243 {*muldi3_1_rex64} (nil)
> (nil))
> Trying to fold rtx:
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff]))
> Returning new rtx:
> (neg:DI (reg/v:DI 67 [ k ]))
Ah. Yes. What did it look like in the tree dumps? Unless
one of the expanders is creating the negation I would think this
would be pretty easy to catch in fold-const.c
[ ... ]
>
> These are the from the detailed .expand dump
> (i.e. "cc1 t.c -O2 --fdump-rtl-expand-details -fdump-rtl-cse")
>
> So it seems to come from the MULT_EXPR expander in this case, but
> we'll have to study expand a bit closer to be sure.
expand_mult? Sigh. That's been in the back of my mind for a couple
years now -- it's probably one of the largest RTL expanders which
needs to have a lot of its functionality moved into trees.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
