On 10/12/2016 01:08 AM, Richard Biener wrote:
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.
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?)
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.