http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> 2011-06-17 08:21:30 UTC --- On Thu, 16 Jun 2011, eraman at google dot com wrote: > 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. Hmm, ok. I guess it can't really do better. > > > > 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? false, yes. Richard.
