This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-1.1.1 issues
- To: law at cygnus dot com, Jason Merrill <jason at cygnus dot com>
- Subject: Re: egcs-1.1.1 issues
- From: Richard Henderson <rth at cygnus dot com>
- Date: Thu, 29 Oct 1998 00:43:28 -0800
- Cc: "H.J. Lu" <hjl at lucon dot org>, egcs-patches at cygnus dot com
- References: <u9d87fbx72.fsf@yorick.cygnus.com> <27593.909632641@hurl.cygnus.com>
- Reply-To: Richard Henderson <rth at cygnus dot com>
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;