On Wed, Nov 28, 2018 at 6:10 PM Jeff Law <l...@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
