On Fri, 29 Apr 2022, Jakub Jelinek wrote: > On Fri, Apr 29, 2022 at 12:58:12PM +0200, Richard Biener wrote: > > So we don't have varpool nodes for the constant pool decls? Are they > > Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through > tree_output_constant_def which does create a varpool node for them > and is generally invoked during GIMPLE passes or so, and using > output_constant_def, which is called during expansion or later and doesn't > have varpool nodes created unless say alias.cc creates those for them. > > > CONST_DECLs at least? I think that's reasonable though ideally we'd > > No, they are VAR_DECLs, mostly created as something to refer to in > SYMBOL_REFs created for the constant pool constants. > varasm.cc (build_constant_desc) creates them. > Changing those from VAR_DECLs to CONST_DECLs could be a lot of work. > > Given that tree_output_constant_def created DECL_IN_CONSTANT_POOL nodes > do have varpool nodes, it might be better to do get first, if it returns > NULL return 0; for !DECL_IN_CONSTANT_POOL otherwise use x_decl2 = x_decl.
Yeah, maybe. That said, the cfgexpand.cc part looks fine to me and probably should fix the compare-debug issue in the PR on its own? Richard. > > be able to assert that there is a symtab node for the decls ... > > > > > I'll need to do some extra checking on whether we don't really lose any > > > useful debug info with the second patch. > > > > At least it was surprisingly simple ;) > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
