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]
Other format: [Raw text]

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)


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