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. Thanks. It's not as much of a hack as you might think.
Right now there's two ways to get at the data we're looking for. One is to query the VRP engine like you've done. The other is to query the expression table which should have something like 1 = (b4 != 0) in it as that expression holds on the 2->3 edge which dominates bb3. One of the things I want to do this summer is integrate the VRP engine queries better into DOM and stop relying on adding conditionals into the expression table (which isn't as powerful and doesn't scale well). So your patch isn't a terrible hack. It's just not the well integrated solution I want to pull together :-) I think it was just last year when I started wondering if we were handling COND_EXPRs on the RHS of an assignment correctly, but it got lost on my stack of TODO items. It's good to have a testcase which confirms my suspicion that we're not handling them as well as we should. I've opened bz86339 to track this issue. Jeff
