From: Harvey Harrison <harvey.harrison-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
mm-commits-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: + kernel-add-common-infrastructure-for-unaligned-access.patch added to -mm tree
Date: Tue, 15 Apr 2008 10:24:32 -0700 [thread overview]
Message-ID: <1208280272.11920.87.camel@brick> (raw)
In-Reply-To: <1208275927.9212.58.camel-ZP4jZrcIevRpWr+L1FloEB2eb7JE58TQ@public.gmane.org>
On Tue, 2008-04-15 at 17:12 +0100, David Woodhouse wrote:
> On Tue, 2008-04-15 at 08:07 -0700, Harvey Harrison wrote:
> > The reason I kept the byte-shifting versions around was that for
> > arches that need special handling of unaligned access,
>
> Are there any? GCC should emit appropriate code for the packed-structure
> version on all architectures, shouldn't it?
>
> > they could do the byteshifting manually and get the unaligned access
> > 'for free' as it were.
>
> GCC really ought to be able to sort that out for itself. Let the dog see
> the rabbit.
Sorry, I didn't explain that very well, let me try again. There is also
some new API along with this patch, for a reason:
This type of pattern, repeat for various byteorder/widths:
le32_to_cpu(get_unaligned((__le32 *)p))
For which the following has been added:
get_unaligned_le32(p)
Which allows BE arches that require special alignment handling to do
the endianness swapping as they do the unaligned accesses. Similarly
for LE arches and the get_unaligned_be*
I realy think gcc will have a hard time seeing that it can fold the
accesses in this way. If you grep for get/put_unaligned you'll
see the majority of the current users actually are wrapping it in
some kind of byteorder access as well...which prompted me to add
this api.
But _if_ gcc is smart enough to fold that together on arches with
special alignment requirements, I'm happy to move to a wrapper
approach.
HPA made the suggestion to look into this method, maybe he can
explain it better than I.
Anyways, I hope I made myself a little clearer this time.
Harvey
WARNING: multiple messages have this Message-ID (diff)
From: Harvey Harrison <harvey.harrison@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>, "H. Peter Anvin" <hpa@zytor.com>
Cc: akpm@linux-foundation.org, mm-commits@vger.kernel.org,
linux-arch@vger.kernel.org
Subject: Re: + kernel-add-common-infrastructure-for-unaligned-access.patch added to -mm tree
Date: Tue, 15 Apr 2008 10:24:32 -0700 [thread overview]
Message-ID: <1208280272.11920.87.camel@brick> (raw)
Message-ID: <20080415172432.m3IWUTS3Bq-XWwcRUkfxE8d2ZgHw0wMmGIzqED-2J8I@z> (raw)
In-Reply-To: <1208275927.9212.58.camel@pmac.infradead.org>
On Tue, 2008-04-15 at 17:12 +0100, David Woodhouse wrote:
> On Tue, 2008-04-15 at 08:07 -0700, Harvey Harrison wrote:
> > The reason I kept the byte-shifting versions around was that for
> > arches that need special handling of unaligned access,
>
> Are there any? GCC should emit appropriate code for the packed-structure
> version on all architectures, shouldn't it?
>
> > they could do the byteshifting manually and get the unaligned access
> > 'for free' as it were.
>
> GCC really ought to be able to sort that out for itself. Let the dog see
> the rabbit.
Sorry, I didn't explain that very well, let me try again. There is also
some new API along with this patch, for a reason:
This type of pattern, repeat for various byteorder/widths:
le32_to_cpu(get_unaligned((__le32 *)p))
For which the following has been added:
get_unaligned_le32(p)
Which allows BE arches that require special alignment handling to do
the endianness swapping as they do the unaligned accesses. Similarly
for LE arches and the get_unaligned_be*
I realy think gcc will have a hard time seeing that it can fold the
accesses in this way. If you grep for get/put_unaligned you'll
see the majority of the current users actually are wrapping it in
some kind of byteorder access as well...which prompted me to add
this api.
But _if_ gcc is smart enough to fold that together on arches with
special alignment requirements, I'm happy to move to a wrapper
approach.
HPA made the suggestion to look into this method, maybe he can
explain it better than I.
Anyways, I hope I made myself a little clearer this time.
Harvey
next prev parent reply other threads:[~2008-04-15 17:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-14 22:14 + kernel-add-common-infrastructure-for-unaligned-access.patch added to -mm tree akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
2008-04-14 22:14 ` akpm
[not found] ` <200804142214.m3EMET5L029431-AB4EexQrvXRQetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-15 12:14 ` David Woodhouse
2008-04-15 12:14 ` David Woodhouse
[not found] ` <1208261668.9212.18.camel-ZP4jZrcIevRpWr+L1FloEB2eb7JE58TQ@public.gmane.org>
2008-04-15 15:07 ` Harvey Harrison
2008-04-15 15:07 ` Harvey Harrison
2008-04-15 16:12 ` David Woodhouse
2008-04-15 16:12 ` David Woodhouse
[not found] ` <1208275927.9212.58.camel-ZP4jZrcIevRpWr+L1FloEB2eb7JE58TQ@public.gmane.org>
2008-04-15 17:24 ` Harvey Harrison [this message]
2008-04-15 17:24 ` Harvey Harrison
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=1208280272.11920.87.camel@brick \
--to=harvey.harrison-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mm-commits-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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