Re: PR 6394

[law at redhat dot com]

In message <200204302128.g3ULSB8S000435@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > >  In message <200204302007.g3UK7DeK000134@hiauly1.hia.nrc.ca>, "John David 
 > > Anglin" writes:
 > >  > DImode is also allowed in FPRs on the PA.  The class used by global_all
 > oc
 > >  > for the pseudo was GENERAL_OR_FP_REGS.  This was the first class select
 > ed
 > >  > for the psuedo and a register %fr22 was selected from this class.
 > > Does the choice of GENERAL_OR_FP_REGS make sense given the uses/sets of
 > > the particular register?  [ I'm probably not going to have time to look
 > > seriously at this today. ]
 > 
 > No.  I would say the class should be GENERAL_REGS.
OK.  A few quick pointers.

The existence of (reg:DI 66) in the RTL is very very suspicious and I think
that's ultimately what's causing this insanely stupid register allocation.

Now the question becomes how did (reg:DI 66) get into the RTL to begin with.
If you look at the decl for Perl_amagic_call, you'll find it sitting in
there.  Not good.

Strip out all the function definitions from your testfile except Perl_amagic_call,
then put a breakpoint in this code in function.c::expand_function_start:

6608              /* Create the pseudo.  */
6609              SET_DECL_RTL (DECL_RESULT (subr), gen_reg_rtx (GET_MODE (hard_reg)));

You'll find that instead of getting a pseudo of the appropriate mode, we
instead get hard reg 66 back from gen_reg_rtx.  Very very bad.  Something
extremely unpleasant is happening here.


jeff