On 07/05/2018 11:39 PM, Richard Biener wrote: > 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. Ah. Presumably the change from 6-16. I'll back that out and retry.
jeff
