This is the mail archive of the gcc-patches@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: GC patches part 4


> +	  rtx constant = get_pool_constant_for_function (f, orig);
> +	  enum machine_mode const_mode = get_pool_mode_for_function (f, orig);

Isn't const_mode == GET_MODE (constant)?  Or is this potentially
SImode for a CONST_INT and such?

> +  function_maybepermanent_obstack
> +    = (struct obstack *) xmalloc (sizeof (struct obstack));
> +  gcc_obstack_init (function_maybepermanent_obstack);
>    maybepermanent_firstobj
>      = (char *) obstack_finish (function_maybepermanent_obstack);
[...]
>    obstack_free (function_maybepermanent_obstack, maybepermanent_firstobj);

Is there any case left in which maybepermanent_firstobj is not
the head of the obstack?  In which case it would be clearer to
not record the point and do obstack_free(..., NULL).

> +  if (obstack_empty_p (function_maybepermanent_obstack))
> +    free (function_maybepermanent_obstack);

Ah.  We don't know?

> +     All structures allocated here are discarded when functions are saved for
> +     inlining, so they do not need to be allocated permanently.  */
> +  struct constant_descriptor **x_const_rtx_hash_table;
> +  struct pool_sym **x_const_rtx_sym_hash_table;

Is this comment still accurate?  Aren't they used through
get_pool_constant_for_function?

I don't see any glaring omissions, though I must admit that
maybefrobulant_obstack and it's ilk make me dizzy.  I can only
believe that we win by giving function-related obstacks the
same lifespan as the function.

IMO the patch is ok.


r~


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