Re: TMSC320C6x port: return label is being deleted

[Adrian StrÃtling<adrian dot straetling at cs dot tu-chemnitz dot de>]

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