Re: PR 6394

[law at redhat dot com]

In message <200204302323.g3UNNLHv000893@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > >  > No.  I would say the class should be GENERAL_REGS.
 > > Agreed now that you've remined me that (reg 66) is a pseudo for PA64 :-)
 > > 
 > > What I find curious is that we have the same cost (0) for 
 > > R1_REGS, GENERAL_REGS and FP_REGS for reg714, yet GENERAL_OR_FP_REGS has
 > > a cost of 7000+?!?  Weird.
 > 
 > This is the insn
 > 
 > (define_insn ""
 >   [(set (match_operand:DI 0 "reg_or_nonsymb_mem_operand"
 > 				"=r,r,r,r,r,r,Q,*q,!f,f,*TR")
 > 	(match_operand:DI 1 "move_operand"
 > 				"A,r,J,N,K,RQ,rM,rM,!fM,*RT,f"))]
 >   "(register_operand (operands[0], DImode)
 >     || reg_or_0_operand (operands[1], DImode))
 >    && ! TARGET_SOFT_FLOAT && TARGET_64BIT"
 > 
 > I believe that the possible alternatives are the first and second last.
 > I don't understand the costs though I can sort of understand thar R1_REGS
 > might be low since %r1 is an input.
The second to last (*RT->f) isn't supposed to match the (MEM (LO_SUM 
(UNSPEC...)))
expression.  That may be why we consider FP_REGS zero cost.  Or it could be
a complete red herring.  I'm still poking at it.

There are days I *really* wish our methods for recognizing a valid address had
more context (load vs store, load destination register type, store source 
register type, etc).  We play far too many unpleasant games in the PA backend
to recognize the asymmetric addressing modes available on the PA.

Anyway, I'm investigating what fixing the 'T' constraint handling does.  At
first glance the costing of the various register classes looks much better
and the abort goes away.

jeff