Re: GCC Status Report (2004-03-09)

[Eric Botcazou <ebotcazou@libertysurf.fr>]

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

> 2004-03-18  Eric Botcazou <ebotcazou@libertysurf.fr>
>             Mark Mitchell <mark@codesourcery.com>
>
> 	PR optimization/13424
> 	* expr.c (store_constructor): Emit a blockage after clearing the
> 	aggregate because of an incomplete or mostly zero constructor.

Well, this pessimizes way too much.  We can emit the blockage only in the 
unsafe cases:


 2004-03-18  Eric Botcazou <ebotcazou@libertysurf.fr>
             Mark Mitchell <mark@codesourcery.com>

 	PR optimization/13424
 	* expr.c (store_constructor): Emit a blockage after clearing the
 	aggregate because of an incomplete or mostly zero constructor if
	the aggregate contains read-only fields.


But this would still pessimize a lot, because life analysis would not be able 
to delete the redundant writes anymore.

-- 
Eric Botcazou

[-- Attachment #2: pr13424-3.diff --]
[-- Type: text/x-diff, Size: 1464 bytes --]

Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.615.4.9
diff -u -p -r1.615.4.9 expr.c
--- expr.c	13 Mar 2004 18:26:23 -0000	1.615.4.9
+++ expr.c	18 Mar 2004 18:14:18 -0000
@@ -4551,8 +4551,9 @@ store_constructor (tree exp, rtx target,
 		       == size)))
 	{
 	  rtx xtarget = target;
+	  bool partly_readonly_p = readonly_fields_p (type);
 
-	  if (readonly_fields_p (type))
+	  if (partly_readonly_p)
 	    {
 	      xtarget = copy_rtx (xtarget);
 	      RTX_UNCHANGING_P (xtarget) = 1;
@@ -4560,6 +4561,19 @@ store_constructor (tree exp, rtx target,
 
 	  clear_storage (xtarget, GEN_INT (size));
 	  cleared = 1;
+
+	  /* ??? Emit a blockage to prevent the scheduler from swapping the
+	     memory write issued just above and the memory write that may be
+	     issued below to initialize each field.  This is needed for a
+	     read-write field because the former write may carry the /u
+	     flag and not the latter, so they will not conflict.  Note that
+	     the clearing cannot be simply disabled in the unsafe cases
+	     because the C front-end relies on it to implement the semantics
+	     of constructors for automatic objects.
+	     However, not all machine descriptions define a blockage insn,
+	     so emit an ASM_INPUT to act as one.  */
+	  if (partly_readonly_p)
+	    emit_insn (gen_rtx_ASM_INPUT (VOIDmode, ""));
 	}
 
       if (! cleared)