Register Allocation Pref. in 3.3.3

[Michael Matz]

Hi,

On Tue, 23 Feb 2010, Paulo J. Matos wrote:

> On Tue, Feb 23, 2010 at 2:26 PM, Dave Korn
> <dave.korn.cygwin@googlemail.com> wrote:
> > On 23/02/2010 13:23, Paulo J. Matos wrote:
> >
> >> That would make sense if the rtx is a set but in this case it is not.
> >> local-alloc.c:set_preference, line 1612 in particular, is called with:
> >> CALL set_preference
> >> dest:
> >> (reg/f:QI 31)
> >> src:
> >> (plus:QI (reg/f:QI 6 Y)
> >> Â  Â  Â  Â  Â  Â  (reg:QI 215))
> >
> > Â So precisely what are those the "src" and "dest" of, then, if not a set rtx?
> >
> 
> Well, the dest and src are from a set, but the line setting preference
> on operands[0] is doing it on the operands of src. So operand[0] of
> src is (reg/f:QI 6 Y)!

First I note that set_preference's comment explicitely says that it's not 
as aggressive as local-alloc in tying register operands together.  Then 
there might be at least the following reasons of why it looks at only the 
first source operand:

1) easier code: there will always be at least one operands for each RTX 
   that goes into src'set_preference.  To access the other codes you would 
   also have to check the length (i.e. if src is binary)
2) faster compile time: checking both operands of a binary is slower
3) two-address machines: Even though binary sets in RTL are three-address 
   form, some popular machines actually are two-address in hardware, with 
   the patterns usually (not always, though) written such that the first 
   source is to be placed into the same reg as the destination.  Hence, if 
   we want to look at only one operand, it usually is better to tie the 
   first source with the dest.  Tieing the second source with dest on a 
   two-address machine, on a non-commutative operation (e.g. minus) 
   actually then would generate worse code than tieing the first with dest 
   due to the necessary shuffle copies.

Especially (3) probably made it look worthless to try exceptionally hard 
to tie the second source with dest.


Ciao,
Michael.