[PATCH] powerpc: Use aligned stores in memset

Steven Munroe munroesj@linux.vnet.ibm.com
Tue Sep 12 19:21:00 GMT 2017


On Tue, 2017-09-12 at 19:04 +0200, Florian Weimer wrote:
> On 09/12/2017 04:16 PM, Steven Munroe wrote:
> > On Tue, 2017-09-12 at 16:08 +0200, Florian Weimer wrote:
> >> * Steven Munroe:
> >>
> >>>> This means that GCC introduced an unaligned store, no matter how memset
> >>>> was implemented.
> >>>>
> >>> C will do what ever the programmer wants. We can not stop that.
> >>
> >> That's not true.  If some specification says that for POWER, mem* must
> >> behave in a certain way, and the GCC/glibc combiniation does not do
> >> that, that's a bug on POWER.
> >>
> > What is the bug that you think we are not fixing?
> 
> memset, as called by the C programmer, still uses unaligned stores.
> 

Are you sure? Which one?

find ./ -name 'memset*' | grep powerpc
./sysdeps/powerpc/powerpc32/power7/memset.S
./sysdeps/powerpc/powerpc32/memset.S
./sysdeps/powerpc/powerpc32/476/memset.S
./sysdeps/powerpc/powerpc32/405/memset.S
./sysdeps/powerpc/powerpc32/power6/memset.S
./sysdeps/powerpc/powerpc32/power4/memset.S
./sysdeps/powerpc/powerpc32/power4/multiarch/memset-ppc32.S
./sysdeps/powerpc/powerpc32/power4/multiarch/memset-power6.S
./sysdeps/powerpc/powerpc32/power4/multiarch/memset.c
./sysdeps/powerpc/powerpc32/power4/multiarch/memset-power7.S
./sysdeps/powerpc/powerpc64/power8/memset.S
./sysdeps/powerpc/powerpc64/power7/memset.S
./sysdeps/powerpc/powerpc64/memset.S
./sysdeps/powerpc/powerpc64/multiarch/memset-power8.S
./sysdeps/powerpc/powerpc64/multiarch/memset-power4.S
./sysdeps/powerpc/powerpc64/multiarch/memset-power6.S
./sysdeps/powerpc/powerpc64/multiarch/memset.c
./sysdeps/powerpc/powerpc64/multiarch/memset-ppc64.S
./sysdeps/powerpc/powerpc64/multiarch/memset-power7.S
./sysdeps/powerpc/powerpc64/power6/memset.S
./sysdeps/powerpc/powerpc64/power4/memset.S

> >> The programmer only sees the entire toolchain, and it is our job to
> >> make the whole thing compliant with applicable specifications, even if
> >> this means coordinating among different projects.
> >>
> >>> And in user mode and cache coherent memory this is not a problem as
> >>> Adhemerval explained.
> >>
> >> Obviously not, otherwise we wouldn't be changing glibc.
> >>
> > I was arguing against forcing GCC and compilers in general being forced
> > to be aware of Cache Inhibited memory. Programmers do.
> 
> Exactly.  In order to give programmers this choice, you need functions
> like device_memset, which are not subject to compiler or library
> optimizations which are not valid for device memory.
> 
Which project is going to host device_memset?

Are you suggesting that GLIBC should?

> > What are you arguing? 
> 
> If you want a memset which is compatible with device memory, you need to
> fix GCC *and* glibc.  Just patching glibc is not enough because GCC
> optimizes memset in ways that are incompatible with your apparent goal..
> 
I still don't see how GCC changes are required for this.

You need to specific here.

We are not going to version every loop that might contain stores based
on speculation that someone who does not know what they are doing might
access Cache Inhibited storage.

Not going to happen.

> Thanks,
> Florian
> 




More information about the Libc-alpha mailing list