http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #29 from davidxl <xinliangli at gmail dot com> 2011-06-18 09:05:10 UTC --- Is Easwaran's patch a reasonable way to go? David (In reply to comment #28) > 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.
