linux-metag.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	"andreas.dilger@intel.com" <andreas.dilger@intel.com>,
	Chen Gang <gang.chen.5i5j@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	"bergwolf@gmail.com" <bergwolf@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-metag@vger.kernel.org" <linux-metag@vger.kernel.org>,
	"oleg.drokin@intel.com" <oleg.drokin@intel.com>,
	"jacques-charles.lafoucriere@cea.fr"
	<jacques-charles.lafoucriere@cea.fr>,
	Antonio Quartulli <antonio@meshcoding.com>,
	netdev <netdev@vger.kernel.org>,
	"jinshan.xiong@intel.com" <jinshan.xiong@intel.com>,
	David Miller <davem@davemloft.net>,
	'Dan Carpenter' <dan.carpenter@oracle.com>
Subject: Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union
Date: Mon, 3 Feb 2014 11:02:58 +0000	[thread overview]
Message-ID: <52EF7762.2060809@imgtec.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B777A@AcuExch.aculab.com>

On 03/02/14 10:35, David Laight wrote:
> From: James Hogan 
>> On 03/02/14 10:05, David Laight wrote:
>>> Architectures that define such alignment rules are a right PITA.
>>> You either need to get the size to 2 without using 'packed', or
>>> just not define such structures.
>>> It is worth seeing if adding aligned(2) will change the size - I'm
>>> not sure.
>>
>> __aligned(2) alone doesn't seem to have any effect on sizeof() or
>> __alignof__() unless it is accompanied by __packed. x86_64 is similar in
>> that respect (it just packs sanely in the first place).
>>
>> Combining __packed with __aligned(2) does the trick though (__packed
>> alone sets __aligned(1) which is obviously going to be suboptimal).
> 
> Compile some code for a cpu that doesn't support misaligned transfers
> (probably one of sparc, arm, ppc) and see if the compiler generates a
> single 16bit request or two 8 bits ones.
> You don't want the compiler generating multiple byte-sized memory transfers.

Meta is also one of those arches, and according to my quick tests,
__packed alone does correctly make it fall back to byte loads/stores,
but with __packed __aligned(2) it uses 16bit loads/stores. I've also
confirmed that with an ARM toolchain (see below for example).

Cheers
James

input:

#define __aligned(x)			__attribute__((aligned(x)))
#define __packed			__attribute__((packed))

union a {
	short x, y;
} __aligned(2) __packed;

struct b {
	short x;
} __aligned(2) __packed;

unsigned int soa = sizeof(union a);
unsigned int aoa = __alignof__(union a);
unsigned int sob = sizeof(struct b);
unsigned int aob = __alignof__(struct b);

void t(struct b *x, union a *y)
{
	++x->x;
	++y->x;
}

ARM output (-O2):

	.cpu arm10tdmi
	.fpu softvfp
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 2
	.eabi_attribute 34, 0
	.eabi_attribute 18, 4
	.file	"alignment4.c"
	.text
	.align	2
	.global	t
	.type	t, %function
t:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	ldrh	r3, [r0, #0]
	add	r3, r3, #1
	strh	r3, [r0, #0]	@ movhi
	ldrh	r3, [r1, #0]
	add	r3, r3, #1
	strh	r3, [r1, #0]	@ movhi
	bx	lr
	.size	t, .-t
	.global	aob
	.global	sob
	.global	aoa
	.global	soa
	.data
	.align	2
	.type	aob, %object
	.size	aob, 4
aob:
	.word	2
	.type	sob, %object
	.size	sob, 4
sob:
	.word	2
	.type	aoa, %object
	.size	aoa, 4
aoa:
	.word	2
	.type	soa, %object
	.size	soa, 4
soa:
	.word	2
	.ident	"GCC: (GNU) 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606)"
	.section	.note.GNU-stack,"",%progbits

  reply	other threads:[~2014-02-03 11:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-18  9:50 [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for the related union Chen Gang
2014-01-18 10:05 ` Dan Carpenter
2014-01-18 10:26   ` Chen Gang
2014-01-18 14:24     ` Dan Carpenter
2014-01-19 10:07       ` Chen Gang
     [not found]         ` <52DBA3D4.3090308-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-01-20 11:56           ` James Hogan
2014-01-20 12:30             ` Dan Carpenter
2014-01-20 12:37               ` James Hogan
2014-01-20 12:56                 ` Dan Carpenter
2014-01-20 13:01                   ` Dan Carpenter
2014-01-20 13:38                     ` James Hogan
2014-01-20 21:13                   ` Dan Carpenter
2014-01-21 10:36                     ` James Hogan
2014-01-25 11:55                       ` Chen Gang
2014-02-01 13:57                         ` Chen Gang
2014-02-03  8:58                           ` Dan Carpenter
2014-02-03 10:03                             ` Chen Gang
     [not found]                               ` <52EF6965.6040406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-02-03 11:35                                 ` Chen Gang
2014-02-03 10:05                             ` David Laight
2014-02-03 10:22                               ` James Hogan
2014-02-03 10:30                                 ` Chen Gang
     [not found]                                 ` <52EF6DCC.6040807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2014-02-03 10:35                                   ` David Laight
2014-02-03 11:02                                     ` James Hogan [this message]
2014-02-03 11:54                                       ` David Laight
     [not found]                               ` <063D6719AE5E284EB5DD2968C1650D6D0F6B772B-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-02-03 10:25                                 ` Chen Gang

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=52EF7762.2060809@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=andreas.dilger@intel.com \
    --cc=antonio@meshcoding.com \
    --cc=bergwolf@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacques-charles.lafoucriere@cea.fr \
    --cc=jinshan.xiong@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oleg.drokin@intel.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 NNTP newsgroup(s).