http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #27 from Easwaran Raman <eraman at google dot com> 2011-06-16 17:14:38 UTC --- (In reply to comment #26) > On Wed, 15 Jun 2011, xinliangli at gmail dot com wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 > > > > davidxl <xinliangli at gmail dot com> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |xinliangli at gmail dot com > > > > --- Comment #23 from davidxl <xinliangli at gmail dot com> 2011-06-15 > > 23:14:50 UTC --- > > (In reply to comment #22) > > > > The DSE patch still leaves 2 redundant stores. > > > > > > OK, I missed this, reopening... > > > > > > > The following patch will enable DSE to remove those two stores. Does > > > > this > > > > look ok? > > > > > > Calling into the gimplifier from the RTL expander doesn't look > > > appropriate. > > It also should use create_tmp_var, not create_tmp_reg. But I wonder why > memory allocated via assign_temp isn't marked in a way to let dse > do its job (I guess dse thinks that memory escapes?). If the mem rtx doesn't have a tree_expression associated with it, DSE assumes the memory escapes. > > > > More fundamentally, it's a little unfortunate to spill to memory a value > > > returned in registers. Can we try to use emit_group_move_into_temps here > > > instead (under the appropriate circumstances)? > > > > It would be nice if the expander does not spill the return into memory in > > the > > first place if possible. On other hand tagging compiler created memory > > location with temp decls so that aliaser has the symbolic information seems > > a > > useful mechanism. > > Sure - but I wonder why assign_temp doesn't do something equivalent > that doesn't require a automatic VAR_DECL to be created. > > Where does the aliaser catch things with the VAR_DECL around that > it doesn't without it? Is it just that when I create a VAR_DECL, TREE_ADDRESSABLE is false and may_be_aliased returns true? > Richard.
