Gentlemen, your feedback would be greatly appreciated!
I was investigating why locals were not being early dumped, and realized
Michael's patch was skipping decls_for_scope() unless
DECL_STRUCT_FUNCTION->gimple_df was set. I assume this was to wait
until location information was available. That design caused locals to
be dumped LATE, which defeats the whole purpose of this exercise.
Since we want the local DECL DIEs to be generated early as well, we'd
want the location information to be amended in the second dwarf pass.
This got me thinking about deferred_locations, and all these on-the-side
data structures that a second dwarf pass would depend on. Unless I'm
misunderstanding something, we need a plan...
Basically, any early collected data that dwarf2out_finish() and
dwarf2out_function_decl() need, would need to be LTO streamed out after
early dwarf generation and streamed back before the second dwarf pass.
For instance, I see at least the following that need to be streamed in/out:
file_table
deferred_locations
limbo_die_list (and deferred_asm_name)
decl_die_table
pubname_table
pubtype_table
We could either stream the hash tables and/or data structures above (and
merge them from different compilation units upon stream-in), or we could
come up with some way of annotating existing dwarf (to be read/merged
back in and annotated). For instance, deferred_locations,
decl_die_table, and limbo_die_lists need to associate a DIE with a TREE.
We could tag the DIE with an artificial DW_AT_* that has some byte
representation of the TREE and recreate the hash at LTO stream-in time.
For other data structures (perhaps file_table and pub*_table), perhaps
we could come up with yet another way of representing the data in Dwarf.
However...I don't know if this is worth the trouble, or if we should
just stream the individual hash tables and data structures, and not
bother with this dwarf gymnastics.
Did anybody have a plan for this? Am I misunderstanding something, or
do we need to stream a lot of these on-the-side structures?
Aldy
