[PATCH 0/3][POPCOUNT]

[Jeff Law]

On 07/05/2018 11:39 PM, Richard Biener wrote:
> On July 6, 2018 12:03:11 AM GMT+02:00, Jeff Law <law@redhat.com> wrote:
>> On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
>>> Hi Jeff,
>>>
>>> Thanks for the comments.
>>>
>>> On 23 June 2018 at 02:06, Jeff Law <law@redhat.com> wrote:
>>>> On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
>>>>> When we set niter with maybe_zero, currently final_value_relacement
>>>>> will not happen due to expression_expensive_p not handling. Patch 1
>>>>> adds this.
>>>>>
>>>>> With that we have the following optimized gimple.
>>>>>
>>>>>   <bb 2> [local count: 118111601]:
>>>>>   if (b_4(D) != 0)
>>>>>     goto <bb 3>; [89.00%]
>>>>>   else
>>>>>     goto <bb 4>; [11.00%]
>>>>>
>>>>>   <bb 3> [local count: 105119324]:
>>>>>   _2 = (unsigned long) b_4(D);
>>>>>   _9 = __builtin_popcountl (_2);
>>>>>   c_3 = b_4(D) != 0 ? _9 : 1;
>>>>>
>>>>>   <bb 4> [local count: 118111601]:
>>>>>   # c_12 = PHI <c_3(3), 0(2)>
>>>>>
>>>>> I assume that 1 in  b_4(D) != 0 ? _9 : 1; is OK (?) because when
>> the
>>>>> latch execute zero times for b_4 == 0 means that the body will
>> execute
>>>>> ones.
>>>> ISTM that DOM ought to have simplified the conditional, unless
>> there's
>>>> some other way to get to bb3.  We know that b_4 is nonzero and thus
>> c_3
>>>> must have the value _9.
>>> As of now, dom is not optimizing it. With the attached hack, it can
>> be made to.
>> What's strange is I'm not getting the c_3 = (b_4 != 0) ... in any of
>> the
>> dumps I'm looking at.  Instead it's c_3 = _9, which is what I would
>> expect since we know that b_4 != 0
>>
>>
>> My tests have been on x86_64 and aarch64 linux targets.  I've tried
>> with
>> patch#1 installed as well as with patch #1 and patch #2 together.
>>
>> What target, what flags and what patches do I need to see this?
> 
> I believe it has been fixed in niters analysis to avoid the condition if it is known to be true. 
Ah.  Presumably the change from 6-16.  I'll back that out and retry.

jeff