https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffreyalaw at gmail dot com --- Comment #14 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Aldy Hernandez from comment #10) > > For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and > removes the check against zero: > > =========== BB 219 ============ > region_type_1384(D) unsigned int VARYING > ctx_1386 struct gimplify_omp_ctx * [1B, +INF] > code_1387(D) tree_code [0, 65535] > outer_ctx_1389 struct gimplify_omp_ctx * VARYING > _2620 bool VARYING > c_3771 union tree_node * [1B, +INF] > _3783 bool VARYING > <bb 219> [local count: 105119385]: > iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80; > iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80; > check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B; > iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389; > > iftmp.2304_1247 : gomp_map_kind [80, 81] > iftmp.2340_1256 : gomp_map_kind [80, 81] > iftmp.2373_1515 : struct gimplify_omp_ctx * [1B, +INF] > > Notice the non-zero range on exit. Looking at how we calculate iftmp.2373_1515, it does actually calculate VARYING for the range on this statement, but intersects that with the known global range picked up from SSA_NAME_PTR_INFO (name)->pt.null Which tags it as a non-null ssa-name for some reason. I put a breakpoint in set_ptr_nonnull() for this ssa-name, and it triggers on: 433 struct ptr_info_def *pi = get_ptr_info (name); (gdb) p print_generic_expr (stderr, name, 0) iftmp.2373_1515 #0 set_ptr_nonnull (name=0x7fffe3b32d80) at /gcc/master/gcc/gcc/tree-ssanames.c:433 #1 0x0000000001aa6857 in find_what_p_points_to (fndecl=0x7fffe50cd100, p=0x7fffe3b32d80) at /gcc/master/gcc/gcc/tree-ssa-structalias.c:6851 #2 0x0000000001aa8c23 in compute_points_to_sets () at /gcc/master/gcc/gcc/tree-ssa-structalias.c:7624 #3 0x0000000001aaa180 in compute_may_aliases () at /gcc/master/gcc/gcc/tree-ssa-structalias.c:8036 #4 0x00000000016425e4 in execute_function_todo (fn=0x7fffe508d240, data=0x100040) at /gcc/master/gcc/gcc/passes.c:2014 #5 0x00000000016415e1 in do_per_function (callback=0x1642515 <execute_function_todo(function*, void*)>, data=0x100040) at /gcc/master/gcc/gcc/passes.c:1687 #6 0x0000000001642935 in execute_todo (flags=1048640) at /gcc/master/gcc/gcc/passes.c:2096 #7 0x0000000001643a22 in execute_one_pass (pass=0x4188b60) at /gcc/master/gcc/gcc/passes.c:2604 #8 0x0000000001643c63 in execute_pass_list_1 (pass=0x4188b60) at /gcc/master/gcc/gcc/passes.c:2656 #9 0x0000000001643c94 in execute_pass_list_1 (pass=0x4188780) at /gcc/master/gcc/gcc/passes.c:2657 #10 0x0000000001643cf3 in execute_pass_list (fn=0x7fffe508d240, pass=0x4188480) at /gcc/master/gcc/gcc/passes.c:2667 #11 0x00000000010cd1ae in cgraph_node::expand (this=0x7fffe4d96220) at /gcc/master/gcc/gcc/cgraphunit.c:1828 It looks like compute_may_aliases decides it's non-null? I set a breakpoint in set_ptr_nonnull if name->>base.u.version == 1515 , and the second time it trips is this variable. Interestingly, vrp1 also then finds this value: Found new range for iftmp.2373_1515: struct gimplify_omp_ctx * [1B, +INF] EQUIVALENCES: { } (0 elements), but that point it is a PHI node: iftmp.2373_1515 = PHI <outer_ctx_288(2090), ctx_4333(2089)> and it proceeds to transform it: gimplify.ii.112t.vrp1: # iftmp.2373_1515 = PHI <outer_ctx_288(2090), ctx_4333(2089)> gimplify.ii.112t.vrp1:Visiting PHI node: iftmp.2373_1515 = PHI <outer_ctx_288(2090), ctx_4333(2089)> gimplify.ii.112t.vrp1:Folding PHI node: iftmp.2373_1515 = PHI <outer_ctx_288(2090), ctx_4333(2089)> gimplify.ii.112t.vrp1: # iftmp.2373_1515 = PHI <outer_ctx_1389(1544), ctx_1386(1543)> and then the lim2 pass converts it from the PHi node to: Moving PHI node iftmp.2373_1515 = PHI <outer_ctx_1389(1393), ctx_1386(1392)> (cost 20) out of loop 1. producing the block as we see it. <bb 215> [local count: 105119385]: iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80; iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80; check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B; iftmp.2373_1515 = code_1387(D) == 181 ? outer_ctx_1389 : ctx_1386; Next, it looks like DOM3 has inserted the condition that is being removed that is problematic? from the .dom3 listing: Optimizing statement if (outer_ctx_1389 != 0B) Replaced 'outer_ctx_1389' with variable 'iftmp.2373_1515' Visiting conditional with predicate: if (iftmp.2373_1515 != 0B) With known ranges iftmp.2373_1515: struct gimplify_omp_ctx * VARYING Predicate evaluates to: DON'T KNOW LKUP STMT iftmp.2373_1515 ne_expr 0B 0>>> COPY iftmp.2373_1515 = 0B <<<< COPY iftmp.2373_1515 = 0B 1>>> STMT 1 = iftmp.2373_1515 ne_expr 0B 1>>> STMT 0 = iftmp.2373_1515 eq_expr 0B Im not sure why dom thinks it is varying when it is globally set to non-null by previous passes, nor exactly what is going on in this transformation, but it definitely rearrange and rewrite code.. someone else can tell me what thats all about... but bottom line is ranger is picking up the [1, +INF] range from another pass setting it. When I run vrp2 with the old vrp, it does not pick up the global range for iftmp.2373_1515, so maybe the VRP pass DOESN'T pick up globals? The first pass actually calculated NON_NULL, DOM3 then transforms the code, and the second pass no longer can detect that it is nonull.. And in fact ranger cannot detect that it is non-null either.. except it picks up the global value produced by vrp1 and folds away the problematic stmt. So maybe someone can comment on what DOM has done here? Or on the stablity of the global table by the time we get to VRP2?