Hi Jeff,
I think you attached the wrong patch to this mail...
Kyrill
On 15/11/17 06:32, Jeff Law wrote:
So the next group of changes is focused on breaking down evrp into an
analysis engine and the actual optimization pass. The analysis engine
can be embedded into other dom walker passes quite easily. I've done it
for the sprintf warnings as well as the main DOM optimizer locally.
Separating analysis from optimization for edge ranges and PHI ranges is
easy. Doing so for statements isn't terribly hard either, but does
require a tiny bit of refactoring elsewhere.
Which brings us to this patch.
If we look at evrp_dom_walker::before_dom_children we'll see this in the
statement processing code:
else if (stmt_interesting_for_vrp (stmt))
{
edge taken_edge;
value_range vr = VR_INITIALIZER;
extract_range_from_stmt (stmt, &taken_edge, &output, &vr);
if (output
&& (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE))
{
update_value_range (output, &vr);
vr = *get_value_range (output);
/* Mark stmts whose output we fully propagate for
removal. */
etc.
Conceptually this fragment is part of the analysis side. But the
subsequent code (optimization side) wants to know the "output" of the
statement. I'm not keen on calling extract_range_from_stmt on both the
analysis side and the optimization side.
So this patch factors out a bit of extract_range_from_stmt and its child
vrp_visit_assignment_or_call into a routine that will return the proper
SSA_NAME. So the analysis side calls extract_range_from_stmt and the
optimization side calls the new "get_output_for_vrp".
And of course to avoid duplication we use get_output_for_vrp from within
vrp_visit_assignment_or_call.
Bootstrapped and regression tested on x86_64. OK for the trunk?
Jeff
