[Bug rtl-optimization/44194] struct returned by value generates useless stores

["xinliangli at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.