From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110062 invoked by alias); 12 Sep 2017 19:21:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 109690 invoked by uid 89); 12 Sep 2017 19:21:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH] powerpc: Use aligned stores in memset From: Steven Munroe Reply-To: munroesj@linux.vnet.ibm.com To: Florian Weimer Cc: Rajalakshmi Srinivasaraghavan , libc-alpha@sourceware.org In-Reply-To: References: <1503033107-20047-1-git-send-email-raji@linux.vnet.ibm.com> <1505223476.12360.14.camel@oc7878010663> <87wp54vwk4.fsf@mid.deneb.enyo.de> <1505225800.12360.28.camel@oc7878010663> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Sep 2017 19:21:00 -0000 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17091219-0044-0000-0000-0000038E58DF X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007713; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000227; SDB=6.00916070; UDB=6.00459980; IPR=6.00696302; BA=6.00005587; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017129; XFM=3.00000015; UTC=2017-09-12 19:21:37 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17091219-0045-0000-0000-000007BD591E Message-Id: <1505244094.12360.36.camel@oc7878010663> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-12_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709120271 X-SW-Source: 2017-09/txt/msg00522.txt.bz2 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 >