On Fri, May 5, 2017 at 10:53 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Note that I tried last stage3 (it ended up being too late) to get rid of ASSERT_EXPRs doing substitute-and-fold itself (basically copy-propagate them out at this point rather than as a separate thing later). This is because the ASSERT_EXPR uses interfere with the single_use checks in match.pd patterns and thus are actually harmful. The barrier I ran into was the ASSERT_EXPR use by the threader ... so now you're making us rely even more on those :/ Richard. > Jeff
