This is the mail archive of the gcc@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: error in finding a register to spill


Shinpei Kato wrote:\
> Could you guess from above info what is going wrong? I don't know why
>  it says 'GR_REGS'. And if I change "=z" to "" in sge_df pattern, it 
> comes to work. So it means there is something wrong about status 
> registers, isn't it?

You said you have only one status register.  In that case, using a hard
register is a much better choice than using a pseudo.  If you use a
pseudo, then the compiler assumes there are an infinite number of them,
and then later when it tries to map them onto one hard register, you
will likely get poor code because of all of the spills required.  You
can avoid this by using a hard register in the first place.  See for
instance the mips port.  It uses a hard reg if there is only one status
register, and a pseudo is there are 8 status registers.

It appears that the compiler ran out of status registers (because there
was only one), and so it has to copy values currently in the status
register to the stack, to free up the status register for register
allocation.  This is called a spill.  This requires having a way to copy
the status register to/from the stack.  There usually aren't normal
instructions for this, so you may have to synthesize one from  other
operations.  This also means you will need a movcc pattern.
Alternatively, you can use secondary reloads, but then things start
getting complicated.  You want to avoid that if you can.  It appears that
you already have a movcc pattern and/or secondary reloads defined,
this caused the compiler to try to move the status register through a
GENERAL_REG to get to the stack, and somehow this failed.  You
might have to step through reload to figure out why.

But it is probably not worth the trouble.  Just use a hard reg instead of
a pseudo to avoid the whole problem.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


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