This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Use aligned stores in memset
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Rajalakshmi Srinivasaraghavan <raji at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Tue, 12 Sep 2017 14:21:34 -0500
- Subject: Re: [PATCH] powerpc: Use aligned stores in memset
- Authentication-results: sourceware.org; auth=none
- References: <1503033107-20047-1-git-send-email-raji@linux.vnet.ibm.com> <b8fd7e0c-8108-a808-a9a2-0c2df8961275@redhat.com> <e04fa334-d4e1-0660-ec26-024e97024761@linux.vnet.ibm.com> <e7daca03-3e86-8cdf-9d42-4e7effb02c63@redhat.com> <d7115391-1e52-5ecb-dce6-57895aaed268@redhat.com> <1505223476.12360.14.camel@oc7878010663> <87wp54vwk4.fsf@mid.deneb.enyo.de> <1505225800.12360.28.camel@oc7878010663> <fcf15935-1cbe-7e2b-5364-366b0c52e3f6@redhat.com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
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
>