Re: Structure Return Testcase

[Graham Stott <grahams at redhat dot com>]

Mark Mitchell wrote:
> 
> >>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
> 
>     Richard> On Thu, Mar 15, 2001 at 01:54:46PM -0700, Jeffrey A Law
>     Richard> wrote:
>     >> Do we think it makes more sense to use memmove or to do the
>     >> copy through a temporary?
> 
>     Richard> Memmove, definitely.  The bits are only shuffled once.
>     Richard> Do that twice and you double memory bandwidth
>     Richard> requirements.
> 
> I agree.
> 
> I also agree that we should use something other than MODIFY_EXPR (or
> perhaps a bit on MODIFY_EXPR itself) that says there might be an
> overlap, rather than looking for RESULT_DECLs.  That's the only way
> we'll ever get it right in the presence of tree-level optimmizations.
> Context-dependent semantics are bad.
> 
>....
> 
> Using memmove everywhere will get us correctness, with some perhaps
> sizable performance hit.
> 
> ...
> after all.  So, we have to be conservative.  If `u' is global or
> addressed, we'll always be conservative.
> 
> But, most structures are addressed, so I'd suggest that the best first
> approximation is to have front-ends set the POSSIBLY_OVERLAPS_P bit on
> MODIFY_EXPRs whenever we're doing a copy from something that might be
> a function-return value.  Then, have expand_expr DTRT.
> 
> BTW, I'm not sure if C++ has this same amendment, but it probably
> should...
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

Are the various API calling conventions w.r.t structure returns going
to come into play here. The one I'm thing of is the hidden pointer how
would the callee know to use memmove and not memcpy?

Graham