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?

For integer constants, GET_MODE (constant) is VOIDmode.
I've tried to mimic the previous code here; it used to call get_pool_mode
as well.

> > +  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?

As I read it, the function_maybepermanent obstack contains stuff that needs
to be preserved for inlining, as well as some types of initializers.  See
preserve_data/preserve_initializer.
We should have a function that frees up all memory for a function that has
been compiled by rest_of_compilation.  That's probably something for the
next patch.

> > +     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?

The problem with comments is that they don't cause test failures even
if they're wrong.  I've fixed this one.

> IMO the patch is ok.

Installed after re-testing with a couple of different targets; with a
couple of updates (e.g. for the new i386 backend).

Bernd


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