On 01/27/2015 12:51 PM, Jason Merrill wrote:
On 01/23/2015 01:45 PM, Aldy Hernandez wrote:
It would expect [the flush] to be before free_lang_data and LTO
streaming.

The reason this wouldn't make a difference is because, as it stands,
dwarf for the clones are not generated until final.c:

   if (!DECL_IGNORED_P (current_function_decl))
     debug_hooks->function_decl (current_function_decl);

which happens after free_lang_data.

I agree that the current code doesn't have this effect, but we're
talking about changing things, right? :)

Oh, my bad. I completely misread your original comment. Yes, yes... we can move the flushing of the limbo list to free_lang_data. See attached patch.


Unfortunately, this sets DECL_ABSTRACT_P for the "static_p" above, and
refuses to unset it after the call to dwarf2out_decl.

Well, that sounds like a bug.  Why isn't it being unset?  Is it because
DECL_ABSTRACT_P was already set for the function, so we don't call
set_decl_abstract_flags (decl, 0)?  Perhaps a solution to that would be
to avoid calling set_decl_abstract_flags (decl, 1) if the function is
already marked as abstract.  Or to teach set_decl_abstract_flags not to
mess with static local variables.

Its' being unset because DECL_ABSTRACT_P was already set. I propose we avoid calling set_decl_abstract_flags() for this scenario, as you suggest, and if this causes any problems, look into your second approach.

The attached patch gets rid of our limbo dependency past LTO streaming by flushing it out early, and adding some sanity checks throughout.

Cilk required some special handholding. It seems to be the only culprit of late FUNCTION_DECL creation.

Now that we call dwarf2out_decl() for clones early on, I had to adjust gen_subprogram_die() to make sure we're not duplicating work and creating a new DIE if we already have on with DW_AT_abstract_origin.

I also kept lookup_filename() uses from ICEing now that we hit this code path. It shouldn't affect other code paths (since it was ICEing before ;-)).

With the attached patch we take care of C++ clones early, and get rid of our dependence on the limbo DIE list into LTO land. No guality regressions.

Are we all in agreement with this approach?

Thanks for everyone's help BTW.
Aldy

Reply via email to