On 11/30/18 12:39 AM, Richard Biener wrote:
> 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.
Agreed, 100%. That was supposed to be where Kai's work was headed, but
we never seemed to make significant headway. Getting BRANCH_COST out
of the tree generation/folding would be a good thing at many levels.
There'll be fallout, of course.
jeff
