[M3devel] unnecessary temporaries
Jay K
jay.krell at cornell.edu
Mon Sep 13 12:40:45 CEST 2010
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