GCC 4.1.2 Port - Is live analysis going wrong?

[Mohamed Shafi]

On Fri, May 16, 2008 at 11:39 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> (insn 211 210 215 1 (set (reg:HI 1 R1 [+2 ])
>>         (subreg:HI (reg/v:SF 207 [ d.104 ]) 2)) 4 {movhi_regmove}
>> (insn_list:REG_DEP_TRUE 208 (nil))
>>     (nil))
>>
>> (call_insn/u 215 211 217 1 (set (reg:HI 0 R0)
>>         (call:HI (mem:HI (reg/f:HI 234) [0 S2 A16])
>>             (const_int 0 [0x0]))) 25 {*call_value_internal_long}
>> (insn_list:REG_DEP_ANTI 207 (insn_list:REG_DEP_ANTI 209
>> (insn_list:REG_DEP_TRUE 213 (insn_list:REG_DEP_TRUE 212
>> (insn_list:REG_DEP_TRUE 211 (insn_list:REG_DEP_TRUE 210
>> (insn_list:REG_DEP_ANTI 208 (nil))))))))
>>     (expr_list:REG_DEAD (reg:SF 2 R2)
>>         (insn_list:REG_RETVAL 210 (expr_list:REG_EH_REGION (const_int
>> -1 [0xffffffff])
>>                 (nil))))
>>     (expr_list:REG_DEP_TRUE (use (reg:SF 2 R2))
>>         (expr_list:REG_DEP_TRUE (use (reg:SF 0 R0))
>>             (nil))))
>> [...]
>> Things go wrong in "call_insn/u 215". Target has R0 and R1 are the
>> parameter registers.
>
> There should probably be a USE for R1 on the call insn then, like for R0.
> Why is it there for the latter and not for the former?
>
> --

This is a 16bit target. SF uses two registers.So There its proper.
But i am still tracing the bug. The problem is for some reason a
definition of R1 is not getting emitted for a library call. This
definition actually defines one of the parameters of the library call.
This call also returns 2 register value, i.e in R0 and R1. So as far
as live analysis is concerned there is a use for R1 but no definition.
And hence it stays live through out the program. I now just need to
find out why the instruction is not getting emitted.

But thanks for taking your time to read this.

Regards,
Shafi