TMSC320C6x port: return label is being deleted

[Adrian Strätling]

Nick Ing-Simmons wrote:

>Graham Stott <graham.stott@btinternet.com> writes:
>
>>>"
>>>
>>You don't need/want all the stuff after after your emit_call_insn
>>
>>In your define_insn for your call you use something like.
>>(define_insn "..."
>> []
>> ""
>>{
>> rtx label = gen_label_rtx ();
>>
>> output your call sequence
>> ..
>>
>> now output the label
>> 
>> return "";
>>}
>>
>>See how the rest of the compiler doesn't know or care
>>about these labels.
>>
>
>I don't know if Adrian's port does this but when I was at TI and 
>playing with a GCC port of C6x I wanted to avoid "clever" output sections.
>Reason was that C6x is a VLIW - so it can execute instructions in parallel.
>So my port tried to make each 'insn' a one-cycle RISC-like one
>(define_expand-ing as required).
>
Yes, I'm trying to do exactly that.

>
>Then there was a custom output pass that walked the RTL and collected 
>RISC-like things into VLIW execute packets.
>Multi-cycle things are a pain in such a scheme.
>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?
Thanks,

Adrian