On 11/28/18 10:47 AM, Michael Eager 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.
I'd start by looking at the state the trees during gimplification then
walk forward or backward as necessary.
Jeff
