On Thu, Mar 18, 2010 at 04:25:03PM +0100, Richard Guenther wrote: > On Wed, 17 Mar 2010, Jakub Jelinek wrote: > > > On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote: > > > That will very much pessimize debug info. While we are now always in > > > -funit-at-a-time mode, that doesn't mean DECL_RTL is computed early > > > enough. > > > From the file scope non-static vars, at the point debug info is generated > > > only > > > the first var usually has DECL_RTL set, all others don't. > > But I see no reason why we couldn't compute DECL_RTL early enough.
Maybe for 4.6, if all code relying on DECL_RTL set meaning it is going to be output is fixed to use some other way, then perhaps we might create DECL_RTL on all varpool symbols that might be needed, before starting output of functions. Before making this change in cfgexpand.c last year I've certainly tried to create DECL_RTL without the SET_DECL_RTL afterwards, and that resulted in many unneeded vars being emitted into assembly. > > ... > > > > And for the dwarf2out.c hunk please see > > http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00546.html > > > > In both spots this happens only for TREE_STATIC && !DECL_EXTERNAL > > variables, and the debug info really doesn't care if the alias set will be 0 > > on all of those MEMs. Though of course it could use the decl's alias set > > if it has been computed already, and 0 otherwise. > > Well, sure. The hack with overriding flag_strict_aliasing will work, > it's still a hack. If we go for it it should be commented as such Yes, we can document it as a hack with a goal to fix eventually. > and be cleaned up properly (I suppose for TREE_STATIC && !DECL_EXTERNAL > we can easily just build the MEM manually instead of computing DECL_RTL > with all its side-effects). We'd have to duplicate most of make_decl_rtl. Stuff like flag_section_anchors handling, etc. Alternative would be to move current make_decl_rtl to make_decl_rtl_1, add a bool argument for_debug and for make_decl_rtl pass false to it. If for_debug it would avoid flag_mudflap handling and avoid the creation of new alias set. Unfortunately not calling set_mem_attributes is not desirable, var-tracking wants to see if such MEM is clobbered by stores and avoiding MEM_EXPR etc. wouldn't be desirable. Ideally we'd even ask for alias set, as long as it is just a read-only operation which doesn't change anything. Jakub
