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: 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


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