Gimpel lowering question.

[Richard Biener]

On Wed, Nov 28, 2018 at 6:10 PM Jeff Law <law@redhat.com> wrote:
>
> On 11/28/18 10:00 AM, Michael Eager wrote:
> > I have a small test case which generates poor quality code on my target.
> > Here is the original:
> >
> >   if (cond1 == 2048 || cond2 == 8)
> >     {
> >       x = x + y;
> >     }
> >   return x;
> >
> > This ends up generating a series of instructions to compute a flag with
> > the result of the condition followed by a single compare with zero and
> > a jump.  Better code would be two compares and two jumps.
> >
> > The gimple is
> >
> >   _1 = cond1 == 2048;
> >   _2 = cond2 == 8;
> >   _3 = _1 | _2;
> >   if (_3 != 0) goto <D.1464>; else goto <D.1465>;
> > ...
> >
> > so this poor code sequence is essentially a correct translation.
> >
> > On MIPS, for the same test case, the gimple is different:
> >
> >   if (cond1 == 2048) goto <D.1491>; else goto <D.1493>;
> >   <D.1493>:
> >   if (cond2 == 8) goto <D.1491>; else goto <D.1492>;
> >   <D.1491>:
> > ...
> >
> > which generates the better code sequence.
> >
> > Can someone give me a pointer where to find where the lowering
> > pass decides to break up a condition into multiple tests?  Is
> > there a target configuration option which I have overlooked or
> > maybe set incorrectly?
> BRANCH_COST, which comes into play during generation of the initial
> trees

Sth I don't like very much...  maybe we can revisit removing
the few cases in fold-const.c (thus GENERIC folding) and rely
on later GIMPLE passes instead plus on RTL expansion to
do the reverse transform.

Not for GCC 9 of course.

>as well in passes which try to optimize branchy code into
> straighter code.
>
> jeff