[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

[amacleod at redhat dot com]

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?