Re: [patches] Re: SSE based conditional moves

[Jan Hubicka <jh at suse dot cz>]

> On Wed, Feb 28, 2001 at 03:24:16PM +0100, Jan Hubicka wrote:
> > ,,, all you need is to unify in your mind.
> 
> But your mental model of how things are unified -- or more to
> the point *ought* to be unified -- does not necessarily coincide
> how the code actually functions.  This disparity may be due to
> not understanding how the code was designed, or due to a bug in
> the code.  Either way it makes things very unfriendly, IMO.
> 
> > Do you have some better idea how the dump should look like?
> 
> If C=union(A,B) is declared to be cheapest, then cost(C) must
> reflect that.  How this is done, I'm not sure, and is exactly
> why I don't like the current state of the patch.  Is it
> 
>   cost(C) = min(cost(A), cost(B))
> 
> i.e. the union is always performed, and we guess that things
> will work out for the best?  Or perhaps it is
> 
>   cost(C) = cost(A) == cost(B) ? cost(A) : cost(C)
> 
> i.e. we choose the union when subclasses are equivalent?
> 
> Right now we get things like INT=0, FP=0, FP_OR_INT=22, which
> is so completely out in left field it makes me think there is
> something wrong with the cost calculations to begin with.

In current tree, these inequalities don't hold eighter -see

int x;
float a,b,e;
test()
{
  float c=a, d=b;
  if (x)
	  c=d;
  e=a;
}

Compiled w/o conditional moves get:


Pass 0

  Register 45 costs: AREG:0 DREG:0 CREG:0 BREG:0 SIREG:0 DIREG:0 AD_REGS:0 Q_REGS:0 NON_Q_REGS:10 INDEX_REGS:0 GENERAL_REGS:10 FP_TOP_REG:0 FP_SECOND_REG:0 FLOAT_REGS:0 FP_TOP_SSE_REGS:12 FP_SECOND_SSE_REGS:12 FLOAT_SSE_REGS:12 FLOAT_INT_REGS:0 INT_SSE_REGS:10 FLOAT_INT_SSE_REGS:12 ALL_REGS:12 MEM:4

  Register 45 pref FLOAT_INT_REGS or none


Pass 1

  Register 45 costs: AREG:0 DREG:0 CREG:0 BREG:0 SIREG:0 DIREG:0 AD_REGS:0 Q_REGS:0 NON_Q_REGS:10 INDEX_REGS:0 GENERAL_REGS:10 FP_TOP_REG:0 FP_SECOND_REG:0 FLOAT_REGS:0 FP_TOP_SSE_REGS:12 FP_SECOND_SSE_REGS:12 FLOAT_SSE_REGS:12 FLOAT_INT_REGS:0 INT_SSE_REGS:10 FLOAT_INT_SSE_REGS:12 ALL_REGS:12 MEM:4

46 registers.

Register 45 used 2 times across 4 insns in block 0; set 1 time; FLOAT_INT_REGS or none.


Since the cost of move is overestimated.  Here is letter I prepared for you. I
am short on time, so it is kind of unfinished, I will write more later.  I will
think about ways to make unions look better in regclass tonight..

> On Wed, Feb 28, 2001 at 03:24:16PM +0100, Jan Hubicka wrote:
> > ,,, all you need is to unify in your mind.
> 
> But your mental model of how things are unified -- or more to
> the point *ought* to be unified -- does not necessarily coincide
> how the code actually functions.  This disparity may be due to
> not understanding how the code was designed, or due to a bug in
> the code.  Either way it makes things very unfriendly, IMO.
The disparity comes from optimistics/pesimistic guesses reg-class is
doing.
Reg-class is pesimistics in a way that when counting cost of moving from
class "A" to class "B", he counts maximal possible cost of moving from
each subclass to each subclass.
This means that moving from "fp_int_regs" to "fp_regs" is cost of moving
from "int_regs" to "fp_regs", instead of 0.

This is neccesary to exclude large classes from the allocation.

On the other hand, reg-class is optimistics in his second pass, by assuming
that register allocator suceeds to place everything in the preferred class and
updates costs accordingly. Currently the cost is updated by the "pessimistics
costs" as described above resulting in weird behaviour.  My patch actually
changes the pessimistics costs to optimistics assuming that register allocator
will do the sane decision.

Simply reg-class can't be consistently pesimistics, since we need realistics
guesses. This brings kind of schizofreny to the algorithm,
> 
> > Do you have some better idea how the dump should look like?
> 
> If C=union(A,B) is declared to be cheapest, then cost(C) must
> reflect that.  How this is done, I'm not sure, and is exactly
> why I don't like the current state of the patch.  Is it
Currently the whole idea behind the patch is to make reg-class working
only on the atomic classes. The union classes just get arbitarily high
costs and thus are excluded from the computation until after the preferencing
is done.
> 
>   cost(C) = min(cost(A), cost(B))
> 
> i.e. the union is always performed, and we guess that things
> will work out for the best?  Or perhaps it is
Yes, thats what we do.
> 
>   cost(C) = cost(A) == cost(B) ? cost(A) : cost(C)
> 
> i.e. we choose the union when subclasses are equivalent?
True too - we always choose just the cheapest classes.
> 
> Right now we get things like INT=0, FP=0, FP_OR_INT=22, which
> is so completely out in left field it makes me think there is
> something wrong with the cost calculations to begin with.
The difference is between the "optimistics" and "pesimistics" choices.
This situation is with current tree too. For example if you force reg-reg
move, it will be computed in the "pesimistics way" for union class.

Honza
> 
> 
> r~