On 05/04/2017 08:37 AM, Jeff Law wrote:
You understanding is slightly wrong however, The ASSERT_EXPRs and
conditionals map 100% through propagation and into simplification. It's
only during simplification that we lose the direct mapping as we change
the conditional in order to remove the unnecessary type conversion.
Threading runs after simplification.
Another approach here would be to simplify the ASSERT_EXPR in the same
manner that we simplify the conditional. That may even be better for
various reasons in the short term. Let me poke at that.
Now I remember why I didn't do that (simplify the ASSERT_EXPR). It
doesn't work :-)
So given an ASSERT_EXPR like:
v1_378 = ASSERT_EXPR <v1_179, v1_179 <= 0>;
Let's assume for the sake of argument v1_179 was set by a type cast from
xx_1. We can simplify that ASSERT_EXPR into
v1_378 = ASSERT_EXPR <v1_179, xx_1 <= 0>;
But note we can not change operand 0 of the ASSERT_EXPR. That would
change the *type* of the ASSERT_EXPR and blows up all kinds of things
later. So the ASSERT_EXPR at best can morph into this form:
v1_378 = ASSERT_EXPR <v1_179, xx_1 <= 0>;
When the threader wants to look for an ASSERT_EXPR that creates a range
for an object, it does lookups based on a match of operand 0 without
digging into the expression in operand 1.
That's something we may want to change in the future (it plays into
issues that arise in patch #3) but in the immediate term it's still best
to defer that one special case of tweaking a GIMPLE_COND.
Jeff
