On July 6, 2018 12:03:11 AM GMT+02:00, Jeff Law <l...@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 <l...@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. Richard. >Jeff
