Hi, On Tue, 23 Feb 2010, Paulo J. Matos wrote:
> On Tue, Feb 23, 2010 at 2:26 PM, Dave Korn > <[email protected]> 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.
