TMSC320C6x port: return label is being deleted

[Nick Ing-Simmons]

=?UTF-8?B?QWRyaWFuIFN0csOkdGxpbmc=?= <adrian.straetling@cs.tu-chemnitz.de> writes:
>>I haven't got my code anymore - I left it at TI.
>>But I seem to recall that my call define expanded 
>>into the load-return and the jump. And the jump had a (fake) dependancy 
>>on the return address register to keep them in right order.
>>
>Thanks, I'll keep that in mind. For the moment I'll stick to the 
>solution that's based on the idea: "the compiler doesn't need to know". 
>The call_expand function inserts the labelno with the appropriate 
>insn_uid of the call insn into a 'private' hash_table. The output code 
>later looks into this table to find the labelno and put it out after the 
>call.
>
>In the same has table I store information about the cycle this insn was 
>scheduled. This way I recognize how many nops (if any) need to be 
>inserted to preserve dependencies.
>The drawback of that solution is that I am not able to use the delay 
>branch scheduler because it destroys those information when regrouping insn.
>
>Do you recall how you did the NOP insertion back then?

I am reasonably sure that I used the normal branch scheduler.
Almost always the "load return" ended up in the delay slots :-)