Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 11 Aug 2013 07:27:54 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memcpy [updated]

On Sun, Aug 11, 2013 at 01:14:31PM +0200, Luca Barbato wrote:
> On 11/08/13 10:13, Rich Felker wrote:
> >> Unfortunately this case seems to be compiling to a call to memcpy on
> >> powerpc (but nowhere else I found). So I may need to drop the special
> >> case for 64-bit alignment. I wish there was some source for knowledge
> >> of the cases that can trigger gcc's stupidity, though...
> > 
> > It turns out mips at certain optimization levels is also generating a
> > memcpy for the structure assignments. I think I just need to drop all
> > of the structure-assignment tricks and use a mildly unrolled loop with
> > uint32_t units for the aligned case. This gives much worse performance
> > on ARM, where gcc fails to generate the proper ldmia/stmia without the
> > struct, but we have asm we can use for ARM anyway. On other archs, the
> > struct copy code does not even seem to help. The simple integer loop
> > works just as well.
> > 
> > I'll do some more experimenting and probably commit the ARM asm soon,
> > followed by the C code once I get some better feedback on how it
> > performs on real machines.
> 
> What about sprinkling volatile here and there?

That might help with gcc 4.8.x issues, but these are already worked
around by turning off the offending optimization, and it seems like
major GCC folks are considering these a bug and hoping to fix them in
an upcoming version anyway.

The structure assignments generating memcpy, however, are a
longstanding bug and are hard-coded in the deep target-specific code
generation. There is no indication that volatile would make them go
away (in fact, I was unable to get it to go away using volatile)
because the memcpy that's being generated is not an abstract
optimization of a series of reads/writes, but being generated directly
out of the signal operation of struct assignment.

While I'd like to see this bug fixed, I don't see any hope of using
struct assignments to implement a C memcpy without some serious
configure tests to make sure it works. There are just too many
combinations of optimization flags, compilers, compiler versions, etc.
that would have to be checked to have any confidence in it not
breaking, and so far it seems ARM (for which we can just use the asm)
is the only arch that would actually benefit from it.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.