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? Jeff
