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]

Re: Machine-dependent bits for GC


> This port declares four global variables for holding RTL, arm_compare_op0, 
> arm_compare_op1, arm_target_insn and aof_pic_label.
> 
> arm_compare_op{0,1} are analogous to the mips branch_cmp[2] declarations, 
> so presumably these need registering (though I'm not entirely sure why, 
> since the life of the variables is generally only from generation of a 
> compare insn through to generation of the branch insn; can GC really 
> happen between these two events?).

Not at the moment.  GC only happens in between optimization passes right
now.  If we wanted it to be more fine grained, there would be many more
places that would need roots added.

> aof_pic_label almost certainly will need registering, since the label put 
> in there will persist until the end of compilation...
> 
>   if (aof_pic_label == NULL_RTX)
>     {
>       /* This needs to persist throughout the compilation.  */
>       end_temporary_allocation ();
>       aof_pic_label = gen_rtx_SYMBOL_REF (Pmode, "x$adcons");
>       resume_temporary_allocation ();
>     }
> 
> Presumably I only need to register this handle if I decide I need to 
> allocate this symbol.  Do I now need to remove the 
> ..._temporary_allocation() calls?

No (at least not yet).  That would introduce a bug for frontends that still
use obstacks (all of them at the present time).

> The fourth variable arm_target_insn is only used during final assembler 
> code generation and is used to point at an insn identified in the chain; I 
> guess this means that I don't need to register this, since the referenced 
> RTL will be always on the main insn chain when the variable is "live".

If it's only live during one pass, it doesn't need registering (it's safe
to register it anyway).

> There is one other "special" in the arm port.  The MACHINE_DEPENDENT_REORG 
> pass uses oballoc to create some temporary structures (see 
> push_minipool_barrier & push_minipool_fix) that only need to persist until 
> the end of that pass.  Am I correct in assuming that these won't need 
> registering, since GC won't run during the pass and the data in them is 
> dead by the end of the pass (or have I got this backwards?).

Anything allocated manually (with oballoc, xmalloc, or other methods) is
invisible to GC, so it doesn't need to be registered unless you put rtl
expressions or trees into structures allocated that way.
In this case, given that the data is local to one pass, you don't need to
register anything.

> Finally, at what point do I need to register all this information?

override_options runs early enough.

Another note: all ports that currently use save_machine_status and
restore_machine_status should be changed to use the new init_machine_status
mechanism to avoid duplication between global vars and variables in struct
function.  That way, you only have to write one mark_machine_status function
to handle them; otherwise you'd need to add GC roots for the globals as well.


Bernd


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