This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs-1.1.1 issues


On Wed, Oct 28, 1998 at 08:44:01PM -0700, Jeffrey A Law wrote:
>   In message <u9d87fbx72.fsf@yorick.cygnus.com>you write:
>   > The second seems to be a problem with the addressof optimization;
>   > fixup_var_refs_1 is creating an unrecognizable insn.  In the ADDRESSOF
>   > case we don't check to make sure that copy_to_reg (y) will be accepted.
>
> Ugh.  More ADDRESSOF problems.  Given the recent ADDRESSOF problems I'd be
> hesitant to try and bring any ADDRESSOF changes from the mainline to the
> branch.  This one may have to stay broken for egcs-1.1.1.

Amazingly, these addressof problems are completely unrelated to 
all of the addressof problems I created a week or three ago.

The base problem seems to me that we go wrong right from the start
in gen_mem_addressof, when we clobber a reg into a mem.  From the .rtl:

(insn 55 53 57 (set (mem:SI (pre_dec:SI (reg:SI 7 %esp)) 0)
        (mem:SI (addressof:SI (reg/v:SI 25) 23) 0)) -1 (nil)
    (nil))

This instruction is illegal, since a push of a mem has been disabled
(actually a mistake, imho, since it is legal for the ISA; it ought
to be available for optional reloads.)

The addressof replacement in fixup_var_refs_1 goes as well as might
be expected from a piece of code that only looks at the addressof down.
It yields

(insn 55 53 57 (set (mem:SI (pre_dec:SI (reg:SI 7 %esp)) 0)
        (mem:SI (reg:SI 32)) -1 (nil)
    (nil))

which lingers on until it gets re-recognized and we barf.

A possible workaround is to take precautions around such mems, 
replacing their address, rerecognizing, and if that fails, 
arbitrarily replace the mem with a reg and pray.

The following patch works at least for this one test case.  I am
not especially happy with it, but I don't know what else to do.


r~



Index: function.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/function.c,v
retrieving revision 1.56
diff -c -p -d -r1.56 function.c
*** function.c	1998/10/28 16:46:46	1.56
--- function.c	1998/10/29 08:32:39
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 1928,1933 ****
--- 1928,1958 ----
  	    replacement->new = copy_most_rtx (x, var);
  
  	  *loc = x = replacement->new;
+ 
+           /* Fixup our subexpression immediately so we can try to determine
+ 	     if a mem is legal at this position at all.  */
+           fixup_var_refs_1 (var, promoted_mode, &XEXP (x, 0), insn,
+ 			    replacements);
+ 
+ 	  /* Rerecognize the insn and see how it goes.  */
+           INSN_CODE (insn) = -1;
+           if (recog_memoized (insn) < 0)
+ 	    {
+ 	      /* Not so good.  It may be the case that gen_mem_addressof
+ 		 has played havock with us.  Try replacing this mem with
+ 		 a reg and hope for the best.  */
+ 
+ 	      rtx tmp;
+ 
+ 	      start_sequence ();
+ 	      tmp = force_reg (GET_MODE (x), x);
+ 	      emit_insn_before (gen_sequence (), insn);
+ 	      end_sequence ();
+ 
+ 	      *loc = x = replacement->new = tmp;
+ 	    }
+ 
+ 	  return;
  	}
        break;
  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]