On Tue, Mar 24, 2020 at 12:37 PM Yangfei (Felix) <felix.y...@huawei.com> wrote: > > Hi! > > > -----Original Message----- > > From: Richard Biener [mailto:richard.guent...@gmail.com] > > Sent: Monday, March 23, 2020 11:25 PM > > To: Yangfei (Felix) <felix.y...@huawei.com> > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [RFC] Should widening_mul should consider block frequency? > > > > On Mon, Mar 23, 2020 at 10:53 AM Yangfei (Felix) <felix.y...@huawei.com> > > wrote: > > > > > > Hi, > > > > > > I created a bug for this issue: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269 > > > Looks like widening_mul phase may move multiply instruction from outside > > the loop to inside the loop, merging with one add instruction inside the > > loop. > > > This will increase the cost of the loop at least on aarch64 (4 cycles > > > vs 1 > > cycle). I think widening_mul should consider block frequency when doing > > such > > a combination. > > > I mean something like: > > > > As written in the PR I'd follow fma generation and restrict defs to the > > same BB. > > Thanks for the suggestion. That should be more consistent. > Attached please find the adapted patch. > Bootstrap and tested on both x86_64 and aarch64 Linux platform.
OK with moving the BB check before the is_widening_mult_p call since it's way cheaper. Thanks, Richard. > gcc: > +2020-03-24 Felix Yang <felix.y...@huawei.com> > + > + PR tree-optimization/94269 > + * tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict this > + operation to single basic block. > > gcc/testsuite: > +2020-03-24 Felix Yang <felix.y...@huawei.com> > + > + PR tree-optimization/94269 > + * gcc.dg/pr94269.c: New test. > + > > Thanks, > Felix