On Wed, Jul 14, 2021 at 7:10 AM Alexandre Oliva <ol...@adacore.com> wrote: > > On Jul 13, 2021, Richard Biener <richard.guent...@gmail.com> wrote: > > > Hmm, elsewhere in this function we're not anticipating future removal but > > instead use ->global_info_ready which IIRC is when the unit was > > initially analyzed. So don't the other uses have the same issue? > > Possibly. > > The call to debug_hooks->late_global_decl in symtab::remove_unused_nodes > is only for varpool nodes, and only variables have initializers that are > expanded as if for non-debug uses, but the initializers *might* > reference function symbols, and that might in turn lead to analogous > codegen differences. I don't have a testcase for that, but it might not > be hard to come up with an analogous one. > > > Maybe reference_to_unused is the wrong tool here and we need a > > reference_to_discardable or so? > > Yeah, back when we expanded debug info very late in compilation, > reference_to_unused was good enough, but now that we process and discard > stuff early, what we really need is some way to avoid issuing a hard > reference to something that might end up not be referenced at all if it > weren't for debug info. > > > In other places we manage to use symbolic DIE references later resolved > > by note_variable_values, can we maybe do this unconditionally for the > > initializers of removed decls somehow? > > That seems doable and desirable. decContext.c doesn't generate location > or const_value for neither mfctop nor mfcone, even after removing > rtl_for_decl_location from add_location_or_const_value_attribute, > despite lookup_decl_loc's finding a location expression. > > I'm afraid I can't really commit to pursuing this any further. > > I'd be glad if someone more familiar with this were to pick this up, but > I haven't managed to come up with a testcase to trigger the problem > without the patchset that I'm not ready to contribute. > > The kicker, in case someone wants to force it, is that at > materialize_all_clones, the reference to mfctop in a constprop-ed > decContextTestEndian gets substituted by its constant initializer, > &mfcone, so mfctop becomes unreachable and goes through late_global_decl > in remove_unreachable_nodes. Eventually, ccp2 resolves the mfcone > dereference to a constant, and no reason remains for mfcone to be > output. However, when outputting debug info, the expand_expr of > mfctop's initializer will have already generated RTL for mfcone, > committing it to be output, wehreas without debug info, mfcone is not > output at all. > > What enables these transformations during IPA is the introduction of a > wrapper for decContextTestEndian, moving its body to a clone that is > materialized early, at the end of all_small_ipa_passes. This clone, > being a local function, seems to be what enables the substitution of the > mfctop constant initializer. I haven't found a way to cause such a > difference without my pass, even getting a constprop (local) clone for > the function, and preventing its inlining into an exported function. > > Hopefully this is enough information to enable the issue to be > investigated.
Can you put the above (and maybe your patch) into a PR so it doesn't get lost? Thanks, Richard. > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice > but very few check the facts. Ask me about <https://stallmansupport.org>
