[PATCH 2/2] tcg/optimize: Flush data at labels not TCG_OPF_BB_END

Richard Henderson posted 2 patches 5 years, 3 months ago
Maintainers: Richard Henderson <rth@twiddle.net>
[PATCH 2/2] tcg/optimize: Flush data at labels not TCG_OPF_BB_END
Posted by Richard Henderson 5 years, 3 months ago
We can easily propagate temp values through the entire extended
basic block (in this case, the set of blocks connected by fallthru),
simply by not discarding the register state at the branch.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
 tcg/optimize.c | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 220f4601d5..9952c28bdc 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -1484,29 +1484,30 @@ void tcg_optimize(TCGContext *s)
                     }
                 }
             }
-            goto do_reset_output;
+            /* fall through */
 
         default:
         do_default:
-            /* Default case: we know nothing about operation (or were unable
-               to compute the operation result) so no propagation is done.
-               We trash everything if the operation is the end of a basic
-               block, otherwise we only trash the output args.  "mask" is
-               the non-zero bits mask for the first output arg.  */
-            if (def->flags & TCG_OPF_BB_END) {
-                bitmap_zero(temps_used.l, nb_temps);
-            } else {
-        do_reset_output:
-                for (i = 0; i < nb_oargs; i++) {
-                    reset_temp(op->args[i]);
-                    /* Save the corresponding known-zero bits mask for the
-                       first output argument (only one supported so far). */
-                    if (i == 0) {
-                        arg_info(op->args[i])->mask = mask;
-                    }
+            /*
+             * Default case: we know nothing about operation (or were unable
+             * to compute the operation result) so no propagation is done.
+             */
+            for (i = 0; i < nb_oargs; i++) {
+                reset_temp(op->args[i]);
+                /*
+                 * Save the corresponding known-zero bits mask for the
+                 * first output argument (only one supported so far).
+                 */
+                if (i == 0) {
+                    arg_info(op->args[i])->mask = mask;
                 }
             }
             break;
+
+        case INDEX_op_set_label:
+            /* Trash everything at the start of a new extended bb. */
+            bitmap_zero(temps_used.l, nb_temps);
+            break;
         }
 
         /* Eliminate duplicate and redundant fence instructions.  */
-- 
2.25.1


Re: [PATCH 2/2] tcg/optimize: Flush data at labels not TCG_OPF_BB_END
Posted by Alex Bennée 5 years, 3 months ago
Richard Henderson <richard.henderson@linaro.org> writes:

> We can easily propagate temp values through the entire extended
> basic block (in this case, the set of blocks connected by fallthru),
> simply by not discarding the register state at the branch.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  tcg/optimize.c | 35 ++++++++++++++++++-----------------
>  1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/tcg/optimize.c b/tcg/optimize.c
> index 220f4601d5..9952c28bdc 100644
> --- a/tcg/optimize.c
> +++ b/tcg/optimize.c
> @@ -1484,29 +1484,30 @@ void tcg_optimize(TCGContext *s)
>                      }
>                  }
>              }
> -            goto do_reset_output;
> +            /* fall through */
>  
>          default:
>          do_default:

A random aside:

The optimize function has a lot of goto's in it and I find generally
hard to follow. Anyway:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée

Re: [PATCH 2/2] tcg/optimize: Flush data at labels not TCG_OPF_BB_END
Posted by Richard Henderson 5 years, 3 months ago
On 10/21/20 7:57 AM, Alex Bennée wrote:
> The optimize function has a lot of goto's in it and I find generally
> hard to follow. Anyway:

Yes.  We'll call it inherited code that could use a re-factor.


r~