On 10/12/2016 01:08 AM, Richard Biener wrote:
On Fri, 7 Oct 2016, Richard Biener wrote:
This turns the switch (which also requires propagating into ASSERT_EXPRs,
otherwise those will end up with released SSA names eventually).
A [3/2] would be to let ASSERT_EXPRs be removed by the propagator
which would a) require VRP to fix up its lattice for this task,
b) make match-and-simplify not be confused by them during
substitute-and-fold folding. This also requires (I think) dealing
with symbolic valueizations during substitute-and-fold in a
way FRE does (track availability) -- currently propagators restrict
themselves to constants due to that (avoid substituting to where
the use does not dominate the definition).
Re-bootstrap / regtest pending on x86_64-unknown-linux-gnu.
The following is what I have applied -- for now we can't DCE ASSERT_EXPRs
because VRP jump threading relies on them (in fact, it looks like VRPs
jump threading "implementation" is nothing but backwards threading,
looking for ASSERT_EXPRs rather than dominating conditions ... Jeff,
you may be more familiar with the VRP threading code, it looks like
we might be able to rip it out without regressions?)
That'd be the one I'd want to see ripped out first as it's the least
"interesting" lot term. I haven't actually tried it though.
I can't remember all the details anymore, but there was some major
headaches around sequencing threading into VRP. IIRC we use two things
from VRP. First the threader knows that an ASSERT_EXPR is just a copy.
Second, it uses the range information via the callback and I believe it
can use those together.
In today's world where range information has become a first class
citizen, there's a reasonable chance that we could drop the ASSERT_EXPRs
from the IL and just query the range information. However, I suspect
we'll see regressions as range information is often lost (the same issue
Aldy, Martin and Andrew have poked at recently).
But it's certainly worth investigation.
jeff
