[M3devel] unnecessary temporaries

Jay K jay.krell at cornell.edu
Mon Sep 13 12:54:03 CEST 2010


Hm, test r003 should show a difference, at least unoptimized, but it doesn't seem to.
I think I'll just #if out my change here unless/until I/anyone can confirm the expected change.
Between min and max, just checking one should suffice.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Mon, 13 Sep 2010 10:40:45 +0000
> Subject: [M3devel] unnecessary temporaries
>
>
> parse.c seems to go crazy sometimes on the temporaries.
>
> Here, in min, max, and check_eq:
>
> Index: parse.c
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
> retrieving revision 1.314
> diff -u -r1.314 parse.c
> --- parse.c    13 Sep 2010 09:59:25 -0000    1.314
> +++ parse.c    13 Sep 2010 10:24:16 -0000
> @@ -4791,11 +4791,8 @@
>  {
>    MTYPE (t);
>
> -  tree t1 = declare_temp (t);
> -  tree t2 = declare_temp (t);
> -
> -  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));
> -  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
> +  tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1)));
> +  tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2)));
>
>    EXPR_REF (-2) = m3_build3 (COND_EXPR, t,
>                               m3_build2 (LE_EXPR, boolean_type_node, t2, t1),
> @@ -4808,11 +4805,8 @@
>  {
>    MTYPE (t);
>
> -  tree t1 = declare_temp (t);
> -  tree t2 = declare_temp (t);
> -
> -  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));
> -  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
> +  tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1)));
> +  tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2)));
>
>    EXPR_REF (-2) = m3_build3 (COND_EXPR, t,
>                               m3_build2 (LE_EXPR, boolean_type_node, t1, t2),
> @@ -5679,11 +5673,10 @@
>    MTYPE2  (t, T);
>    INTEGER (code);
>
> -  tree temp1 = declare_temp (t);
> -  tree temp2 = declare_temp (t);
> -
> -  m3_store (temp1, 0, t, T, t, T);
> -  m3_store (temp2, 0, t, T, t, T);
> +  tree temp1 = stabilize_reference (m3_cast (t, EXPR_REF (-1)));
> +  tree temp2 = stabilize_reference (m3_cast (t, EXPR_REF (-2)));
> +  EXPR_POP ();
> +  EXPR_POP ();
>    add_stmt (build3 (COND_EXPR, t_void,
>                      m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2),
>                      generate_fault (code),
>
>
> and in the unoptimized
>
> m3core/src/text/TextCat
>
> PROCEDURE MyGetChars (t: T;  VAR a: ARRAY OF CHAR;  start: CARDINAL) =
>   VAR u: TEXT;  a_offset, t_offset, u_offset: CARDINAL := 0;
>   BEGIN
>     u := t.a;
>     IF (t_offset + t.a_len > start) THEN
>       u_offset := MAX (start - t_offset, 0);
>       u.get_chars (SUBARRAY (a, a_offset, NUMBER (a) - a_offset), u_offset);
>
>
>
> 7 instructions go down to 3, 4 memory operations saved, and 16 bytes of stack are saved (presumably 12, rounded)
>
>
>
> --- I386_DARWIN.3/TextCat.ms    2010-09-13 03:18:45.000000000 -0700
> +++ I386_DARWIN.4/TextCat.ms    2010-09-13 03:19:40.000000000 -0700
> @@ -835,7 +835,7 @@
>  LCFI41:
>      movl    %esp, %ebp
>  LCFI42:
> -    subl    $88, %esp
> +    subl    $72, %esp
>  LCFI43:
>      movl    -16(%ebp), %eax
>      andl    $0, %eax
> @@ -879,18 +879,14 @@
>      movl    16(%ebp), %eax
>      cmpl    %eax, %edx
>      jle    L54
> -    movl    $0, -32(%ebp)
>      movl    16(%ebp), %edx
>      movl    -20(%ebp), %eax
>      movl    %edx, %ecx
>      subl    %eax, %ecx
>      movl    %ecx, %eax
> -    movl    %eax, -36(%ebp)
> -    movl    -36(%ebp), %edx
> -    movl    -32(%ebp), %eax
> -    cmpl    %edx, %eax
> -    jge    L49
> -    movl    %edx, %eax
> +    testl    %eax, %eax
> +    jns    L49
> +    movl    $0, %eax
>
>
> Reasonable, eh?
> Or should I be nervous?
>
>
> check_eq in particular -- if you get it wrong, such that it is underaggressive, correct programs
> will work the same.
>
>
> I guess I should make sure m3tests is full of failure cases for that.
> Ok, in m3front, it looks like all the uses of check_eq are related to runtime assignments
> of open arrays, to make sure their sizes match, or such, either for assignment or passing a parameter.
>
>
>  - Jay
>
>
 		 	   		  


More information about the M3devel mailing list