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

Reply via email to