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
commit 0618a201f59699d48fd68edac10d9ad9da6b4c54
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Nov 15 06:30:31 2017 +0000

            * explow.c (anti_adjust_stack_and_probe_stack_clash): Avoid probing
            the red zone for stack_clash_protection_final_dynamic_probe targets
            when the total dynamic stack size is zero bytes.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@254753 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c404eb8e5a7..08642663d95 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
 2017-11-14  Jeff Law  <l...@redhat.com>
 
+       * explow.c (anti_adjust_stack_and_probe_stack_clash): Avoid probing
+       the red zone for stack_clash_protection_final_dynamic_probe targets
+       when the total dynamic stack size is zero bytes.
+
        * tree-ssa-threadupdate.c (thread_through_all_blocks): Thread
        blocks is post order.
 
diff --git a/gcc/explow.c b/gcc/explow.c
index 662865d2808..96334b2b448 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -1999,6 +1999,13 @@ anti_adjust_stack_and_probe_stack_clash (rtx size)
   if (size != CONST0_RTX (Pmode)
       && targetm.stack_clash_protection_final_dynamic_probe (residual))
     {
+      /* SIZE could be zero at runtime and in that case *sp could hold
+        live data.  Furthermore, we don't want to probe into the red
+        zone.
+
+        Go ahead and just guard a probe at *sp on SIZE != 0 at runtime
+        if SIZE is not a compile time constant.  */
+
       /* Ideally we would just probe at *sp.  However, if SIZE is not
         a compile-time constant, but is zero at runtime, then *sp
         might hold live data.  So probe at *sp if we know that
@@ -2011,9 +2018,12 @@ anti_adjust_stack_and_probe_stack_clash (rtx size)
        }
       else
        {
-         emit_stack_probe (plus_constant (Pmode, stack_pointer_rtx,
-                                          -GET_MODE_SIZE (word_mode)));
+         rtx label = gen_label_rtx ();
+         emit_cmp_and_jump_insns (size, CONST0_RTX (GET_MODE (size)),
+                                  EQ, NULL_RTX, Pmode, 1, label);
+         emit_stack_probe (stack_pointer_rtx);
          emit_insn (gen_blockage ());
+         emit_label (label);
        }
     }
 }

Reply via email to