This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gimpel lowering question.


On Wed, Nov 28, 2018 at 9:47 AM Michael Eager <eager@eagerm.com> wrote:
>
> On 11/28/18 09:10, Jeff Law 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 as well in passes which try to optimize branchy code into
> > straighter code.
>
> Thanks.  I did look at BRANCH_COST, and played with the values, but it
> didn't seem to have any affect.  I'll take a closer look.

Look at LOGICAL_OP_NON_SHORT_CIRCUIT .  By defualt, it is defined as:
  (BRANCH_COST (optimize_function_for_speed_p (cfun), \
                false) >= 2)
But MIPS defines it as 0.

Changing  LOGICAL_OP_NON_SHORT_CIRCUIT to 0 will disable this optimization.

LOGICAL_OP_NON_SHORT_CIRCUIT controls both places where (cond1 == 2048
|| cond2 == 8) would remove the branch.

NOTE I think MIPS defines LOGICAL_OP_NON_SHORT_CIRCUIT incorrectly but
that is a different story.

Thanks,
Andrew Pinski


>
> --
> Michael Eager    eager@eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]