public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com>
To: Florian Weimer <fweimer@redhat.com>,
	Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] powerpc: Use aligned stores in memset
Date: Wed, 13 Sep 2017 13:12:00 -0000	[thread overview]
Message-ID: <87mv5yhhdh.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <d7115391-1e52-5ecb-dce6-57895aaed268@redhat.com>

Florian Weimer <fweimer@redhat.com> writes:

> On 08/18/2017 11:10 AM, Florian Weimer wrote:
>> On 08/18/2017 08:51 AM, Rajalakshmi Srinivasaraghavan wrote:
>>>
>>>
>>> On 08/18/2017 11:51 AM, Florian Weimer wrote:
>>>> On 08/18/2017 07:11 AM, Rajalakshmi Srinivasaraghavan wrote:
>>>>>     * sysdeps/powerpc/powerpc64/power8/memset.S: Store byte by byte
>>>>>     for unaligned inputs if size is less than 8.
>>>>
>>>> This makes me rather nervous.  powerpc64le was supposed to have
>>>> reasonable efficient unaligned loads and stores.  GCC happily generates
>>>> them, too.
>>>
>>> This is meant ONLY for caching inhibited accesses.  Caching Inhibited
>>> accesses are required to be Guarded and properly aligned.
>> 
>> The intent is to support memset for such memory regions, right?  This
>> change is insufficient.  You have to fix GCC as well because it will
>> inline memset of unaligned pointers, like this:
>
> Here's a more complete example:
>
>
> #include <assert.h>
> #include <stdio.h>
> #include <string.h>
>
> typedef long __attribute__ ((aligned(1))) long_unaligned;
>
> __attribute__ ((noinline, noclone, weak))
> void
> clear (long_unaligned *p)
> {
>   memset (p, 0, sizeof (*p));
> }
>
> struct data
> {
>   char misalign;
>   long_unaligned data;
> };
>
> int
> main (void)
> {
>   struct data *data = malloc (sizeof (*data));
>   assert (data != NULL);
>   long_unaligned *p = &data->data;
>   printf ("pointer: %p\n", p);
>   clear (p);
>   return 0;
> }
>
> The clear function compiles to:
>
> typedef long __attribute__ ((aligned(1))) long_unaligned;
>
> void
> clear (long_unaligned *p)
> {
>   memset (p, 0, sizeof (*p));
> }
>
> At run time, I get:
>
> pointer: 0x10003c10011
>
> This means that GCC introduced an unaligned store, no matter how memset
> was implemented.

Which isn't necessarily a problem.
The performance penalty only appears when the memory access is referring
to an address which isn't at the instruction's natural boundary.

In this case, memset should use stb to avoid an alignment interrupt.

Notice that if the memory access is not at the natural boundary, an alignment
interrupt is generated and it won't generate an error.  The access will still
happen, but it will have a performance penalty.

> So I think the implementation constraint on the mem* functions is wrong.
>  It leads to a slower implementation of the mem* function for most of
> userspace which does not access device memory, and even for device
> memory, it is probably not what you want.

Makes sense.  But as there is nothing in the standard allowing or prohibiting
the usage of mem* functions to access caching-inhibited memory, I thought it
would make sense to provide functions that are as generic as possible.

IMHO, it's easier for programmers to use generic functions in most scenarios
and have access to specialized functions, e.g. a function for data already
aligned at 16 bytes.

-- 
Tulio Magno

  parent reply	other threads:[~2017-09-13 13:12 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
2017-09-12 19:45                   ` Florian Weimer
2017-09-12 20:25                     ` Steven Munroe
2017-09-13 13:12         ` Tulio Magno Quites Machado Filho [this message]
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=87mv5yhhdh.fsf@linux.vnet.ibm.com \
    --to=tuliom@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).