This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reload problem
> 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.
Here are some statistics obtained with a big C++ file from Lyx at -O2:
input reloads optimized
x86 7872 0
SH -m4 26301 1422 (5%)
SPARC 205 0
"input reloads" means input reloads pushed by push_reload that reach the
optimization point,
"optimized" means those among "input reloads" that meet the conditions and
are optimized.
Note that I didn't check that the expression to be reloaded is a PLUS. Since
gen_reload does its own private reload only for a PLUS, we could restrict
the recognizing process to PLUSes.
> 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.
Yes, of course, this would not be as safe as recognizing.
> 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.
Yes, we would exchange compile-time slowdown with run-time slowdown.
> 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.
Ok, I'm going to patch push_reload.
Thanks again.
--
Eric Botcazou