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

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.

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

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.

> I just run SPECInt2000 on x86 (-O2) without and with 2nd pass for today
> trunk.

I would love to redo the test on MIPS, but SPECInt is hardly suitable for
embedded, even if source was available.

> 2nd pass permits to reduce code size 1.36% in average, requires 0.2% more
> compilation time, and
> improves performance by 2.6%.

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