Re: Reload problem

[Jim Wilson <wilson at specifixinc dot com>]

On Thu, 2003-09-11 at 02:09, Eric Botcazou wrote:
> It is my understanding that recognizing insns is an expensive process, so I 
> think that adding it to push_reload would be the last resort solution.

Yes, it is expensive, so we want to avoid doing it too often.  It is
however the only test that exactly describes the condition we are
looking for.  Anything else will require compromising in some cases.

How often does this special case code in push_reload trigger?  If it
happens only rarely, then the extra cost of recognizing insns would be
acceptable.

> Could we extend the scope of the LEGITIMATE_CONSTANT_P macro, by adding a 
> second argument PLUS_CLASS that would be specified as follows:

I'm not sure about modifying LEGITIMATE_CONSTANT_P.  It has been around
forever.  Maybe a LEGITIMATE_PLUS_CONSTANT_P macro?

It isn't clear whether this safely solves the problem.  There may be
targets that accept different constant ranges for different addition
modes.  There may be targets that accept different constant ranges for
different source/destination register classes, but you are only looking
at one reg class..  There may be targets that accept different constant
ranges for 2-address vs 3-address add instructions.  The fact that some
targets have only 2-address adds means that gen_reload still has to have
special code for emitting adds that effectively transforms one reload
into two.  So I don't see this issue as a convincing reason for a change
to find_reloads_address_part.

It may be hard to write an accurate version of this macro which doesn't
add too many unnecessary extra reloads.  This macro will duplicate info
that is already in the patterns in the md file.

Maybe a few extra reloads here aren't a problem if a post-reload cse
pass cleans them up.

I am undecided about what to do here.

Here is another suggestion.  In push_reloads, if the value being
reloaded is an addition (GET_CODE (in) == PLUS), then we only perform
the optimization if it is valid as a memory address.  This is overly
conservative, since many targets can handle larger add immediates than
they can handle address offsets.  This is a lose for IA-64 which has no
REG+COSNT address mode though.  If that is too much of a lose, then
maybe we put the LEGITIMATE_PLUS_CONSTANT_P test here in gen_reload
instead of find_reloads_address_part.

Another consideration here is that modifying find_reloads_address_part
will change the set of reloads created, which will change the behaviour
of reload in difficult to predict ways, and possibly cause other
problems.  Changing push_reload is just disabling an optimization, which
should be much less likely to cause other problems.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com