public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Steven Munroe <munroesj@linux.vnet.ibm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>,
	libc-alpha@sourceware.org
Subject: Re: [PATCH] powerpc: Use aligned stores in memset
Date: Tue, 12 Sep 2017 19:21:00 -0000	[thread overview]
Message-ID: <1505244094.12360.36.camel@oc7878010663> (raw)
In-Reply-To: <fcf15935-1cbe-7e2b-5364-366b0c52e3f6@redhat.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
> 


  reply	other threads:[~2017-09-12 19:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-18  5:13 Rajalakshmi Srinivasaraghavan
2017-08-18  6:21 ` Florian Weimer
2017-08-18  6:51   ` Rajalakshmi Srinivasaraghavan
2017-08-18  9:10     ` Florian Weimer
2017-08-18 12:13       ` Adhemerval Zanella
2017-09-12 10:30       ` Florian Weimer
2017-09-12 12:18         ` Zack Weinberg
2017-09-12 13:57           ` Steven Munroe
2017-09-12 14:37           ` Joseph Myers
2017-09-12 15:06             ` Zack Weinberg
2017-09-12 17:09           ` Florian Weimer
2017-09-12 13:38         ` Steven Munroe
2017-09-12 14:08           ` Florian Weimer
2017-09-12 14:16             ` Steven Munroe
2017-09-12 17:04               ` Florian Weimer
2017-09-12 19:21                 ` Steven Munroe [this message]
2017-09-12 19:45                   ` Florian Weimer
2017-09-12 20:25                     ` Steven Munroe
2017-09-13 13:12         ` Tulio Magno Quites Machado Filho
2017-09-18 13:54           ` Florian Weimer
2017-10-03 18:29             ` Adhemerval Zanella
2017-10-05 12:13               ` Rajalakshmi Srinivasaraghavan
2017-11-08 18:52               ` Tulio Magno Quites Machado Filho
2017-12-08 19:52                 ` [PATCHv2] powerpc: POWER8 memcpy optimization for cached memory Tulio Magno Quites Machado Filho
2017-12-08 20:06                   ` Florian Weimer
2017-12-11 12:44                     ` Tulio Magno Quites Machado Filho
2017-12-11 20:09                       ` Adhemerval Zanella
2017-12-10  7:11                   ` Rajalakshmi Srinivasaraghavan
2017-12-11 19:48                     ` Tulio Magno Quites Machado Filho
2017-08-18  6:25 ` [PATCH] powerpc: Use aligned stores in memset Andrew Pinski
2017-08-21  2:20 ` Tulio Magno Quites Machado Filho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1505244094.12360.36.camel@oc7878010663 \
    --to=munroesj@linux.vnet.ibm.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=raji@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).