This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TMSC320C6x port: return label is being deleted
- From: Nick Ing-Simmons <nick at ing-simmons dot net>
- To: graham dot stott at btinternet dot com
- Cc: GCC <gcc at gcc dot gnu dot org>,Adrian "Strätling" <adrian dot straetling at cs dot tu-chemnitz dot de>
- Date: Mon, 04 Oct 2004 14:00:45 +0100
- Subject: Re: TMSC320C6x port: return label is being deleted
- References: <20040916180303.14790.qmail@web86108.mail.ukl.yahoo.com>
- Reply-to: Nick Ing-Simmons <nick at ing-simmons dot net>
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).
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,
>> Adrian
>>
>
>Graham