From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John David Anglin" To: gcc@gcc.gnu.org Subject: Re: pa reload problem Date: Sat, 30 Dec 2000 11:17:00 -0000 Message-id: <200012301917.OAA19171@hiauly1.hia.nrc.ca> X-SW-Source: 2000-12/msg00872.html Forwarded message: >From dave Sat Dec 30 14:05:51 EST 2000 Message-Id: <200012301905.OAA19130@hiauly1.hia.nrc.ca> Subject: Re: pa reload problem To: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Sat, 30 Dec 2000 14:05:50 -0500 (EST) From: "John David Anglin" Cc: rth@redhat.com, alan@linuxcare.com.au, law@cygnus.com, rhirst@linuxcare.com, parisc-linux@thepuffingroup.com, gcc-bugs@gcc.gnu.org In-Reply-To: <200012221721.MAA00889@hiauly1.hia.nrc.ca> from "John David Anglin" at Dec 22, 2000 12:21:54 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Your GO_IF_LEGITIMATE_ADDRESS will accept the UNSPEC? > > The mind boggles. Why, then, is this strange beast its own insn? > > I have done some more testing. As I do more work trying to build the pa port under hpux 10.20 with `-fPIC -O3', I have begun to understand why this strange beast is its own insn. The machine definition which I am testing currently has the UNSPEC integrated with other move_operands. However, in doing this, I have encountered another reload problem. Here is the relevant rtl from the lreg pass: ;; Function init_all_optabs ... (note 223 107 225 ("insn-opinit.c") 48 -1347440721) (insn 225 223 1961 (set (reg/f:SI 611) (plus:SI (reg:SI 19 %r19) (high:SI (symbol_ref:SI ("target_flags"))))) 80 {*pa.md:2326} (nil) (nil)) ... (note 1063 1013 1067 ("insn-opinit.c") 130 -1347440721) (insn 1067 1063 2002 (set (reg/f:SI 403) (mem/u:SI (lo_sum:SI (reg/f:SI 611) (unspec:SI[ (symbol_ref:SI ("target_flags")) ] 0)) 0)) 69 {*pa.md:2099} (nil) (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611) (unspec:SI[ (symbol_ref:SI ("target_flags")) ] 0)) 0) (expr_list:REG_DEAD (reg/f:SI 611) (nil)))) ... (note 2006 1059 1069 ("insn-opinit.c") 130 -1347440721) (insn 1069 2006 2007 (set (reg:SI 404) (mem/f:SI (reg/f:SI 403) 4)) 69 {*pa.md:2099} (insn_list 1067 (nil)) (expr_list:REG_EQUIV (mem/f:SI (reg/f:SI 403) 4) (nil))) ... (note 1085 1926 1091 ("insn-opinit.c") 132 -1347440721) (insn 1091 1085 1094 (set (reg:SI 411) (mem/f:SI (reg/f:SI 403) 4)) 69 {*pa.md:2099} (nil) (expr_list:REG_EQUIV (mem/f:SI (reg/f:SI 403) 4) (nil))) ... (note 2168 1597 1607 ("insn-opinit.c") 194 -1347440721) (insn 1607 2168 2169 (set (reg:SI 538) (mem/f:SI (reg/f:SI 403) 4)) 69 {*pa.md:2099} (insn_list:REG_DEP_ANTI 1497 (nil)) (expr_list:REG_EQUIV (mem/f:SI (reg/f:SI 403) 4) (nil))) ... (note 1621 1931 1627 ("insn-opinit.c") 196 -1347440721) (insn 1627 1621 1630 (set (reg:SI 544) (mem/f:SI (reg/f:SI 403) 4)) 69 {*pa.md:2099} (nil) (expr_list:REG_DEAD (reg/f:SI 403) (nil))) Note that register 611 is dead at insn 1067. However, we still have REG_EQUIV notes which implicitly use register 611 on insns 1091 and 1607 (not sure why there isn't a note on 1627). This leads to disaster at insn 1607 when the hard register assigned to 611 gets reused for other purposes in the intervening code. Is the REG_DEAD note for register 611 in the right place? Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)