On Mon, Feb 22, 2010 at 2:12 PM, Joern Rennecke
<joern.renne...@embecosm.com> wrote:
> Quoting "Paulo J. Matos" <pocma...@gmail.com>:
>
>> Hi,
>>
>> For anyone who still remembers what went on with 3.3.3, in global.c,
>> set_preference, why is there a bias to set preference for operand 0 of
>> src?
>
> I don't remember the detail of this specific code, but in general operand 0
> is mostly used as an output operand; if an output operand can be assigned
> a register, it is likely to be needed in a subsequent instruction to do
> something with it.
>
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))
operator[0] is a register, as is operator[1] of src. So what's the
reason for the bias?
>> - Does the order in which define_insn and define_expand rules show up
>> in the .md file bias the compiler to choose a rule in one way or the
>> other?
>
> You may not have more than one pattern with the same name. define_insn
> patterns will not be used for instruction pattern nor split point
> recognition.
>
>> - If two define_insn patterns match the same insn, which one will be used?
>
> The first one to be recognized. This is not necessarily the same as the
> first
> one in the file, because insn code numbers are cached, and in general not
> recomputed during or after reload. If the insn code caching has an effect
> on eventual instruction selection, it is usually a bug in the machine
> description.
>
Thanks for the reply.
--
PMatos
