This is the mail archive of the gcc-patches@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: [ira-improv] patch for new code dealing with hard reg preferences


On 13-04-05 4:48 PM, Jeff Law wrote:
On 04/05/2013 02:14 PM, Vladimir Makarov wrote:
   The following patch adds a new functionality to IRA to improve RA in
presence of hard registers in RTL.  IRA already had some mechanism
dealing with hard regs but it affected only pseudos in *the same insn*
containing hard register.  This technique was not good enough to
remove regmove pass code making transformations for matching
constraints (e.g. 2-op insn machine) although IRA can make better
decision for pseudos but still not enough good for hard registers.  So
just removing the code in regmove resulted in worse generated code
performance.

   On the other hand there are performance PRs which is a result of bad
decision in pre-mature optimization of regmove pass for matching
constraints.

   We already have an IRA code propagating pseudo preferences to other
pseudos through net of copies.  We need the same code for better
dealing with hard register preferences.  The patch adds such code.  I
could modify structure ira_copy for this but decided to use new
separate structures as the copy structure is too big and we don't need
most of its fields for hard-register preferences.

   By the way, LRA has already code for dealing with hard register
preferences but in simplified way as we work on RTL mostly locally.

   This is not a final patch as the big part of regmove code and old
IRA code for hard register preferences are not removed.  This code is
just switched off by -fira-hard-reg-pref option.  I am going to play a
bit more with the new code and when I decide to submit it to trunk, I
remove the unnecessary code and the option.

   Right now, the results look pretty good for SPEC2000 on x86/x86-64.
The compiler is always faster (as a regmove RTL pass is switched
off), generates in average smaller code (the best is 0.05% decrease
for x86-64 SPECFP2000), and generates in average better code (0.6%
and 0.4% SPECFP2000 improvement on x86 and x86-64 correspondingly).
The results were gotten on Intel Core I7-2600 in -O3 optimization
mode.

   The patch was successfully bootstrapped on x86/x86-64 with the new
code switched on.

Committed as rev. 197525.
Very cool. Presumably this is meant to kill optimize_reg_copy_*. That'd leave the fixup_match bits (which might be dead with the SLSR in the mainline. Does that just leave try_auto_increment?

Yes, I think so. Unfortunately, no IRA/LRA has analogous code. As I remember this code still important for targets with small displacements and even for x86/x86-64: although it has no practically constraints.on displacements, it affects x86/x86-64 code size and as a consequence the performance too (through better code locality).

Still removing one pass through RTL is a good result although removing 2 passes would be better.



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