On 8/18/21 1:31 AM, Andrew MacLeod wrote:
And this final patch provides tracing in the GORI component.
This is what I used to find the ABS problem with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
The code sequence looked like:
<bb 2> :
a1_8 = -arg1_7(D);
_1 = ABS_EXPR <arg2_9(D)>;
a2_10 = -_1;
if (a1_8 > a2_10)
goto <bb 3>; [INV]
and the threader was threading a condition later on because the outgoing
range for arg2_9 was being compared to 0x80000000 and folded to [0,0]
as it didnt think that could happen.
The GORi trace looked like:
237 GORI outgoing_edge for arg2_9(D) on edge 2->3
238 GORI compute op 2 (a2_10) at if (a1_8 > a2_10)
GORI LHS = _Bool [1, 1], a1_8 = int64 VARYING
GORI Computes a2_10 = int64 [-INF, 9223372036854775806]
intersect Known range : int64 VARYING
GORI TRUE : (238) produces (a2_10) int64 [-INF,
9223372036854775806]
239 GORI compute op 1 (_1) at a2_10 = -_1;
GORI LHS =int64 [-INF, 9223372036854775806]
GORI Computes _1 = long long int [-INF,
-INF][-9223372036854775806, +INF] intersect Known range : long long int
VARYING
GORI TRUE : (239) produces (_1) long long int [-INF,
-INF][-9223372036854775806, +INF]
240 GORI compute op 1 (arg2_9(D)) at _1 = ABS_EXPR <arg2_9(D)>;
GORI LHS =long long int [-INF, -INF][-9223372036854775806,
+INF]
GORI Computes arg2_9(D) = int64 [-9223372036854775807,
+INF] intersect Known range : int64 VARYING
GORI TRUE : (240) produces (arg2_9(D)) int64
[-9223372036854775807, +INF]
GORI TRUE : (237) outgoing_edge (arg2_9(D)) int64
[-9223372036854775807, +INF]
Thanks for doing this. I really like the breakpoint routine. It has
always been incredibly tricky debugging through the cascade of GORI and
range-ops operations.
Do you think it would be useful to put the actual SSA name instead, or
as well as, "LHS"? Perhaps something similar to what you do with
"compute op 1 (x_99)".
Aldy
