[RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call

[RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]


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

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 2133 bytes --]

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  <law@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);
 	}
     }
 }

Re: [RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call

[Kyrill Tkachov]

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

Re: [RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call

[Jeff Law]

On 11/15/2017 03:45 AM, Kyrill Tkachov wrote:
> Hi Jeff,
> 
> I think you attached the wrong patch to this mail...
Yup.  Totally botched it.  Correct version already resent.

Oh how I wish for the days where my mail client would show me my own
attachments inline :(  Though I'd had enough cold medicine that it might
not have made any difference the other night.


jeff