[llvm-dev] Dataflow analysis regression in 3.7

Johan Engelen via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 6 08:55:31 PDT 2017


On Thu, Jul 6, 2017 at 7:00 AM, Davide Italiano <davide at freebsd.org> wrote:

> On Wed, Jul 5, 2017 at 3:59 PM, Johan Engelen via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hi all,
> >   I just found an optimization regression regarding simple
> > dataflow/constprop analysis:
> > https://godbolt.org/g/Uz8P7t
> >
> > This code
> > ```
> > int dataflow(int b) {
> >   int a;
> >
> >   if (b==4)
> >     a = 3*b; // fully optimized when changed to a = 3;
> >   else
> >     a = 5;
> >
> >   if (a == 4)
> >     return 0;
> >   else
> >     return 1;
> > }
> > ```
> > is no longer optimized to just a "return 1". The regression happened in
> LLVM
> > 3.6 --> 3.7.
> >
> > Is this a known regression? I couldn't find it in the bug tracker (but
> don't
> > really know which keywords to look for...)
> >
> > Kind regards,
> >   Johan
> >
>
> This regressed when SimplifyCFG changed the threshold for PHI nodes
> folding from 1 to 2.
>
> (see lib/Transforms/Utils/SimplifyCFG.cpp)
>
> +PHINodeFoldingThreshold("phi-node-folding-threshold", cl::Hidden,
> cl::init(2),
> +   cl::desc("Control the amount of phi node folding to perform
> (default = 2)"));
>
> This could be re-evaluated, maybe, or some other transformation could
> catch this case.
>

I'm sure that adjusting that threshold has many implications, so I don't
want to touch that.


> (e.g. a more powerful range solver could realize that a is always in
> the range [5;12]).
>

I seem to have been very "lucky" in finding the non-optimized case. I get
fully optimized output when replacing "3*b" with "2*b" or "4*b" or
"b+b+b+b" or "3*b-b"... But for "3*b", "b+b+b", and "3*b+6" things go wrong.
Is there another optimization pass interfering?

regards,
  Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/6358c945/attachment.html>


More information about the llvm-dev mailing list