This is the mail archive of the 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: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult

On 05/30/2012 10:27 PM, Klaus Pedersen wrote:
Thanks for the pointer,

On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov<> wrote:
Here is an extract from my article from GCC Summit 2004 proceedings.

  It is interesting to note that the pass also implicitly does code
selection.  Regclass works in two passes.  On the first pass, it
defines the preferred and alternative classes without taking the
possible classes of other operands into account.
I had a problem similar to Richard, I simply couldn't figure out what
the second pass tried to do. I ended up single stepping and
printf'fing. I still didn't get much clearer on what was going on.

2nd pass was a part of the old RA for long time for a reason.

For example, an
instruction with two operand pseudo-registers exists in two variants;
one accepting classes {\em A} and {\em B}, and other one accepting
{\em C} and {\em D}.  On the first pass, the algorithm does not see
that the variant with classes {\em A} and {\em D} will be more costly
because it will require the generation of additional move
instructions.  On the second pass, the algorithm will take it into
account. As a result the preferred or alternative class of a
pseudo-register could change.  This means two passes are not enough to
find the preferred and alternative classes accurately; but it is a
good approximation.
On my MIPS target (1000's of files) I never saw that second pass gives
better code (for practical reasons - smaller size!). I will try to redo
and sumerize these results on a clean 4.7 and with the simple fixes
later today.
The effect of 2nd pass may be target depended. The problem with RA being most target dependent code is that one code is trying to work well for all targets.
If I change the ACC_REGS penalty from 6 to 3 in mips_move_to_gpr_cost()
I get some improvement. MIPS1 need the accumulator for all mult
and div operations, so there are no point in this penalty that makes the
ACC more expensive than FP and memory.

My question is - if the first pass gives you a valid hard register -
shouldn't that be the default if second gives you something bad like
NO_REGS? It is not that you can generate better code if you have been
forced to reload from memory.

The only problem is how to know that the 2nd pass makes worse choice. The 2nd pass should give not a worse choice. It is not true now for MIPS. We will try to fix it.
I just run SPECInt2000 on x86 (-O2) without and with 2nd pass for today
I would love to redo the test on MIPS, but SPECInt is hardly suitable for
embedded, even if source was available.

I guess the run will take forever. So please, don't bother with this at least untill your problem will be fixed.
2nd pass permits to reduce code size 1.36% in average, requires 0.2% more
compilation time, and
improves performance by 2.6%.
There is a simple solution for your problem which I mentioned in my email. Unfortunately, it slows down x86 compiler by 0.5% which I believe is big. So I'll search another solution.

Thanks for reporting this problem and sorry for a long wait.

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