[llvm-commits] llvm-gcc aggregate copy

[Chris Lattner]

On May 27, 2008, at 11:46 PM, Duncan Sands wrote:

> Hi Chris, I discussed this problem with Dale some time ago.
> Since gcc mainline produces exactly the same memcpy call, we
> decided not to worry about it.  I do remember a gcc guy telling
> me once that aggregate assignment assumes no overlap, so maybe
> there is nothing to worry about...

Ah right.

> My personal feeling is that
> memmove should be used and llvm should change it to memcpy if
> it can deduce that it is safe.

This would be nice.  If there is no measurable perf impact on any code  
we care about, then I guess we could do this.  It seems that lots of  
the cases that occur in practice will be to stack objects, which are  
relatively easy to disambiguate.

> There is also the problem of
> small structs for which llvm-gcc produces a hand-made memcpy,
> i.e. a series of loads and stores.  That would need to be turned
> into something that works for overlapping objects.  One possibility
> (inefficient but works) is to compare the addresses of the two
> objects and copy in order of increasing address or decreasing address
> correspondingly.  A better solution is perhaps to exploit the new
> aggregates-as-first-class-values work and treat small structs as
> registers.

Ok.  Lets evaluate this option as Dan's work gets farther along.

-Chris