On Tue, 12 Apr 2016, Jakub Jelinek wrote: > On Tue, Apr 12, 2016 at 08:19:57PM +0200, Richard Biener wrote: > > >So you mean add another hash table that maps DECL_UIDs to these SRA > > >counters? Because if we dump there any number of say FIELD_DECL, it > > >would > > >be desirable to use the same number on any further fancy names with > > >that > > >FIELD_DECL. > > >Do it unconditionally, or just for flag_dump_final_insns? > > > > I'd have just added sth to the dumps so you can manually connect the XXX in > > the name with the UID. > > But the names appear in all the gimple, ipa? and rtl dumps after that, so > if it e.g. just printed a SRA uid -> DECL uid mapping in tree-sra*-details > dump, then one would not have it easily accessible when looking all the > other dumps.
Sure - but does it really matter? Usually decls also have names. > If it is just guarded with flag_dump_final_insns != NULL, then we have the > previous behavior almost all the time, just for -fcompare-debug effectively > force -nouid flag into all the dumps for the fancy names. But it is easy > to just remove that flag from the command line to have more details, IMHO > that is better than just looking up some mapping dump somewhere. I hate to change behavior of passes based on unrelated flags. Over-engineering things just in case you need to debug sth is also bad. So if you think it's not acceptable to drop the relation between the artificial number used by SRA and the original UID then go with a hash-map unconditionally. You still have to dump and lookup the actual relation though - there's no way around this unless you hack dump-final-insns to filter DECL names (maybe just make it strip all DECL_ARTIFICIAL names completely?) Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
