This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]