http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #35 from Easwaran Raman <eraman at google dot com> 2011-06-20
16:51:18 UTC ---
(In reply to comment #33)
> > I think these two are totally independent of each other -- one should not be
> > gated against each other. If Eawaran's approach is completely flawed, that
> > is
> > different story. With this change, we at least make incremental
> > improvement.
> > Not familiar with the rtl expander, but I guess the spilling was there
> > probably
> > for a deeper reason. If you have an insight, you can of course point it out.
>
> See comment #22. It's an incremental improvement, but maybe we can avoid
> wasting time and memory by creating RTXes and Trees that will be thrown away
> immediately after. I don't really see what we risk by trying.
There is a comment in calls.c that says
/* Handle calls that return values in multiple non-contiguous locations.
The Irix 6 ABI has examples of this. */
I don't know if avoiding the copy breaks that ABI in any way so I didn't try
that approach. In general, if the TARGET is non-NULL, I don't see how the copy
can be avoided (but then, the tree EXPR corresponding to the target hopefully
has the addressable flag set). In this particular case though TARGET is NULL.
Is it just a matter of setting VALREG and let expand_assignment deal with it?
Irrespective of how this case is handled, I think there may be other instances
where a store generated during expansion may be redundant, but we don't know it
at the point of generation. In such cases, is this approach of associating a
tree expr with the temp rtx generated by the expanded reasonable?
