This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-64 on HP-UX 11.00
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: law at redhat dot com
- Cc: h dot m dot brand at hccnet dot nl, gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 May 2002 12:11:18 -0400 (EDT)
- Subject: Re: gcc-64 on HP-UX 11.00
> Even so, we should know that we need to allocate a GPR to handle the
> symbol_ref operand. This would tend to indicate a problem in
> secondary_reload_class
I did some more investigation of the problem over the weekend but haven't
come to any final conclusions. It does appear that secondary_reload_class
needs to provide a GPR to handle this situation. However, this didn't
seem to change the situation.
With the predicate of the xmpyu patterns changed to register_operand
and rejecting all LO_SUMs in the 'T' constraint, I get an ICE in stage1
compiling f/data.c with "-mpa-risc-2-0" on this insn:
(insn 582 576 2521 (set (reg:DI 332)
(mem/f:DI (lo_sum:SI (reg/f:SI 873)
(symbol_ref:SI ("ffedata_arraysize_"))) [29 ffedata_arraysize_+0 S8 A64])) 118 {*pa.md:3247} (nil)
(expr_list:REG_DEAD (reg/f:SI 873)
(nil)))
../../gcc/gcc/f/data.c: In function `ffedata_advance_':
../../gcc/gcc/f/data.c:655: insn does not satisfy its constraints:
(insn 2638 563 582 (set (reg:DI 70 %fr23 [332])
(mem/f:DI (lo_sum:SI (reg/f:SI 4 %r4 [873])
(symbol_ref:SI ("ffedata_arraysize_"))) [29 ffedata_arraysize_+0 S8 A64])) 118 {*pa.md:3247} (nil)
(nil))
../../gcc/gcc/f/data.c:655: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8367
The strange thing is the same insn reloads sucessfully without "-mpa-risc-2-0".
I am still convinced that under PA 2.0 the code is better if we directly
load the the MEM. The above reload stuff seems fragile. Sometimes, I have
seen the value loaded to a register, copied to the stack, and then loaded
to the FPR with a short displacement load. Sometimes, the address of the
MEM is used which is much better.
I have discovered that gas and ld don't properly handle the relocation
needed to do the FPR load directly under PA 2.0 (the "t" bit in position 30
isn't handled properly). Alan said it would be a fair bit of work to fix.
I'm travelling for the rest of the week, so I can't look further into this
until next week.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)