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: Graham Stott <graham dot stott at btinternet dot com>
- To: "Adrian_Strätling" <adrian dot straetling at cs dot tu-chemnitz dot de>, gcc at gcc dot gnu dot org
- Date: Tue, 14 Sep 2004 19:09:05 +0100 (BST)
- Subject: Re: TMSC320C6x port: return label is being deleted
Adrain,
--- Adrian_Strätling <adrian.straetling@cs.tu-chemnitz.de> wrote:
> Hi all,
>
>
[snip]
> This architecture does not have a specific call instruction, so we had
> to produce the following code:
>
> "
> push ret_label
> move b_label, breg
> branch breg
>
> ret_label:
> ...
> "
Yep this label is going to go walkies because it doesn't appear in the CFG.
>
> so the callee can pop the return address from the stack and jump there.
> In gcc version 3.3 after jump optimization 'ret_label' is present as a
> CODE_LABEL_DELETED_INSN,
> but in version 3.5 I can't find it
>
[snip]
>
You've just been lucky with 3.3
> I have been able to avoid the deletion of the label by changing:
> "emit_label (ret_label);"
> into
> "LABEL_PRESERVE_P( emit_label (ret_label) ) = 1;"
> but on the one hand I don't think that's the way it has been meant (no
> one else does so) and on the other it only works without optimization.
> The scheduler would move the label next to the function label. I guess
> it handles it not as a code_label but as a note when it does so.
>
That *will* keep the label but it won't keep it in the right place!
> Does anyone know a solution to this?
Yes, The optimizers, etc don't need or want to know about this label it's an
artifact of your call sequence, so keep it hidden.
You only need a label to appear in the generated .s file so your call
pattern can take care of making one up when the time comes to output your
call fragment.
>
> Thanks in advance,
>
> greets,
> Adrian Strätling
>
Graham