[RFC] LTO and debug information
Richard Guenther
rguenther@suse.de
Sun Dec 13 20:51:00 GMT 2009
On Sun, 13 Dec 2009, Michael Matz wrote:
> Hi,
>
> On Sun, 13 Dec 2009, Richard Guenther wrote:
>
> > *************** free_lang_data_in_decl (tree decl)
> > *** 4380,4408 ****
> > }
> > }
> >
> > ! if (TREE_CODE (decl) == PARM_DECL
> > ! || TREE_CODE (decl) == FIELD_DECL
> > ! || TREE_CODE (decl) == RESULT_DECL)
> > ! {
> > ! tree unit_size = DECL_SIZE_UNIT (decl);
> > ! tree size = DECL_SIZE (decl);
> > ! if ((unit_size && TREE_CODE (unit_size) != INTEGER_CST)
> > ! || (size && TREE_CODE (size) != INTEGER_CST))
> > ! {
> > ! DECL_SIZE_UNIT (decl) = NULL_TREE;
> > ! DECL_SIZE (decl) = NULL_TREE;
> > ! }
> > !
> > ! if (TREE_CODE (decl) == FIELD_DECL
> > ! && DECL_FIELD_OFFSET (decl)
> > ! && TREE_CODE (DECL_FIELD_OFFSET (decl)) != INTEGER_CST)
> > ! DECL_FIELD_OFFSET (decl) = NULL_TREE;
> > !
> > ! /* DECL_FCONTEXT is only used for debug info generation. */
> > ! if (TREE_CODE (decl) == FIELD_DECL)
> > ! DECL_FCONTEXT (decl) = NULL_TREE;
> > ! }
>
> Ugh. If you remove this, add an 'FIXME' comment, in case we ever get the
> early-debuginfo generation. We do want to nullify these eventually, and
> it's sufficiently tricky to free the right things without introducing
> strange errors so that we don't want to invest the time to find out the
> details again. Right now we still remember, but in one year ... :)
I'll replace it with
+ /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
+ and DECL_FIELD_OFFSET. But it's cheap enough to not do
+ that and refrain from adding workarounds to dwarf2out.c */
+
+ /* DECL_FCONTEXT is only used for debug info generation. */
+ if (TREE_CODE (decl) == FIELD_DECL
+ && debug_info_level < DINFO_LEVEL_TERSE)
+ DECL_FCONTEXT (decl) = NULL_TREE;
+
the non-constant sizes and offset are gimplified and thus
only a single decl. IMHO it's not a good idea to make
those types incomplete (even if nothing should really look
at their sizes). We can deal with DECL_FCONTEXT like with
TYPE_STUB_DECL.
Richard.
More information about the Gcc
mailing list