From: "Måns Rullgård" <mans@mansr.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>, "Nicolas Pitre" <nico@fluxnic.net>, "Will Deacon" <Will.Deacon@arm.com>, "Måns Rullgård" <mans@mansr.com>, lkml <linux-kernel@vger.kernel.org>, ak@linux.intel.com, "Andrew Morton" <akpm@linux-foundation.org>, sam@ravnborg.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Date: Fri, 27 May 2011 13:46:38 +0100 [thread overview] Message-ID: <yw1xlixse2fl.fsf@unicorn.mansr.com> (raw) In-Reply-To: <20110527095111.GC21100@e102109-lin.cambridge.arm.com> (Catalin Marinas's message of "Fri, 27 May 2011 10:51:11 +0100") Catalin Marinas <catalin.marinas@arm.com> writes: > On Fri, May 27, 2011 at 09:54:14AM +0100, Russell King - ARM Linux wrote: >> >> Ok, we need to check one last thing, and that's what the behaviour is >> with -mno-unaligned-access and packed structures (such as the ethernet >> header). If it makes no difference, then I suggest we always build >> with -mno-unaligned-access. > > I tried some simple code below: > > struct test { > unsigned char a[6]; > unsigned long b; > } __attribute__((packed)); > > void set(struct test *t, unsigned long v) > { > t->b = v; > } > > int main(void) > { > struct test t; > > set(&t, 10); > > return 0; > } > > With -mno-unaligned-access in newer toolchains, the set() function looks > like this (compiled with -march=armv7): > > 00000000 <set>: > 0: e7e7c451 ubfx ip, r1, #8, #8 > 4: e7e72851 ubfx r2, r1, #16, #8 > 8: e1a03c21 lsr r3, r1, #24 > c: e5c01006 strb r1, [r0, #6] > 10: e5c0c007 strb ip, [r0, #7] > 14: e5c02008 strb r2, [r0, #8] > 18: e5c03009 strb r3, [r0, #9] > 1c: e12fff1e bx lr > > If I don't pass -mno-unaligned-access later toolchains use unaligned > accesses by default and the set() function is more efficient: > > 00000000 <set>: > 0: e5801006 str r1, [r0, #6] > 4: e12fff1e bx lr This is certainly something we should want. Although some people expressed concerns over introducing unaligned accesses where there were previously none, I don't see how this could pose a problem as long as we make sure strict alignment checking is off. Some basic testing of code paths known to use unaligned accesses should suffice IMO. > The problem is that in addition to that we also get unaligned stack > variables which are not really efficient. Either way we have a drawback > somewhere. We could argue that -fconserve-stack is badly implemented on > ARM. Unless someone can demonstrate a clear win from -fconserve-stack, I think it's pretty obvious that this flag does more harm than good on ARM, especially in conjunction with unaligned accesses being allowed. If the stack packing could be disabled while retaining the other (presumably beneficial) effects of -fconserve-stack, it might be reconsidered. -- Måns Rullgård mans@mansr.com
WARNING: multiple messages have this Message-ID (diff)
From: mans@mansr.com (Måns Rullgård) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Date: Fri, 27 May 2011 13:46:38 +0100 [thread overview] Message-ID: <yw1xlixse2fl.fsf@unicorn.mansr.com> (raw) In-Reply-To: <20110527095111.GC21100@e102109-lin.cambridge.arm.com> (Catalin Marinas's message of "Fri, 27 May 2011 10:51:11 +0100") Catalin Marinas <catalin.marinas@arm.com> writes: > On Fri, May 27, 2011 at 09:54:14AM +0100, Russell King - ARM Linux wrote: >> >> Ok, we need to check one last thing, and that's what the behaviour is >> with -mno-unaligned-access and packed structures (such as the ethernet >> header). If it makes no difference, then I suggest we always build >> with -mno-unaligned-access. > > I tried some simple code below: > > struct test { > unsigned char a[6]; > unsigned long b; > } __attribute__((packed)); > > void set(struct test *t, unsigned long v) > { > t->b = v; > } > > int main(void) > { > struct test t; > > set(&t, 10); > > return 0; > } > > With -mno-unaligned-access in newer toolchains, the set() function looks > like this (compiled with -march=armv7): > > 00000000 <set>: > 0: e7e7c451 ubfx ip, r1, #8, #8 > 4: e7e72851 ubfx r2, r1, #16, #8 > 8: e1a03c21 lsr r3, r1, #24 > c: e5c01006 strb r1, [r0, #6] > 10: e5c0c007 strb ip, [r0, #7] > 14: e5c02008 strb r2, [r0, #8] > 18: e5c03009 strb r3, [r0, #9] > 1c: e12fff1e bx lr > > If I don't pass -mno-unaligned-access later toolchains use unaligned > accesses by default and the set() function is more efficient: > > 00000000 <set>: > 0: e5801006 str r1, [r0, #6] > 4: e12fff1e bx lr This is certainly something we should want. Although some people expressed concerns over introducing unaligned accesses where there were previously none, I don't see how this could pose a problem as long as we make sure strict alignment checking is off. Some basic testing of code paths known to use unaligned accesses should suffice IMO. > The problem is that in addition to that we also get unaligned stack > variables which are not really efficient. Either way we have a drawback > somewhere. We could argue that -fconserve-stack is badly implemented on > ARM. Unless someone can demonstrate a clear win from -fconserve-stack, I think it's pretty obvious that this flag does more harm than good on ARM, especially in conjunction with unaligned accesses being allowed. If the stack packing could be disabled while retaining the other (presumably beneficial) effects of -fconserve-stack, it might be reconsidered. -- M?ns Rullg?rd mans at mansr.com
next prev parent reply other threads:[~2011-05-27 12:46 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-23 11:16 [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Catalin Marinas 2011-05-23 12:30 ` Måns Rullgård 2011-05-23 13:25 ` Russell King - ARM Linux 2011-05-23 13:21 ` Russell King - ARM Linux 2011-05-23 13:51 ` Catalin Marinas 2011-05-23 14:37 ` Måns Rullgård 2011-05-23 14:41 ` Catalin Marinas 2011-05-23 14:52 ` Russell King - ARM Linux 2011-05-24 9:39 ` Catalin Marinas 2011-05-24 14:17 ` Måns Rullgård 2011-05-24 15:26 ` Catalin Marinas 2011-05-24 16:23 ` Måns Rullgård 2011-05-24 17:26 ` Nicolas Pitre 2011-05-24 17:13 ` Dave Martin 2011-05-25 11:14 ` Catalin Marinas 2011-05-25 12:43 ` Dave Martin 2011-05-25 13:32 ` Måns Rullgård 2011-05-25 14:05 ` Dave Martin 2011-05-25 14:48 ` Måns Rullgård 2011-05-25 14:50 ` Catalin Marinas 2011-05-25 14:53 ` Måns Rullgård 2011-05-26 17:10 ` Will Deacon 2011-05-26 17:10 ` Will Deacon 2011-05-26 18:14 ` Måns Rullgård 2011-05-26 18:14 ` Måns Rullgård 2011-05-26 19:58 ` Andi Kleen 2011-05-26 19:58 ` Andi Kleen 2011-05-26 21:03 ` Nicolas Pitre 2011-05-26 21:03 ` Nicolas Pitre 2011-05-26 21:10 ` Andi Kleen 2011-05-26 21:10 ` Andi Kleen 2011-05-26 21:26 ` Måns Rullgård 2011-05-26 21:26 ` Måns Rullgård 2011-05-27 10:05 ` Will Deacon 2011-05-27 10:05 ` Will Deacon 2011-05-27 16:53 ` Andi Kleen 2011-05-27 16:53 ` Andi Kleen 2011-05-26 21:51 ` Russell King - ARM Linux 2011-05-26 21:51 ` Russell King - ARM Linux 2011-05-26 22:29 ` Andi Kleen 2011-05-26 22:29 ` Andi Kleen 2011-05-27 8:38 ` Catalin Marinas 2011-05-27 8:38 ` Catalin Marinas 2011-05-27 8:54 ` Russell King - ARM Linux 2011-05-27 8:54 ` Russell King - ARM Linux 2011-05-27 9:51 ` Catalin Marinas 2011-05-27 9:51 ` Catalin Marinas 2011-05-27 9:56 ` Catalin Marinas 2011-05-27 9:56 ` Catalin Marinas 2011-05-27 12:46 ` Måns Rullgård [this message] 2011-05-27 12:46 ` Måns Rullgård 2011-05-28 15:34 ` [PATCH] Disable -fconserve-stack on ARM Andi Kleen 2011-05-28 15:34 ` Andi Kleen 2011-05-31 16:30 ` Catalin Marinas 2011-05-31 16:30 ` Catalin Marinas 2011-05-31 18:01 ` Andi Kleen 2011-05-31 18:01 ` Andi Kleen 2011-06-02 13:08 ` Catalin Marinas 2011-06-02 13:08 ` Catalin Marinas [not found] <mailman.254.1306496353.1533.linux-arm-kernel@lists.infradead.org> 2011-05-27 12:14 ` [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Frank Hofmann
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=yw1xlixse2fl.fsf@unicorn.mansr.com \ --to=mans@mansr.com \ --cc=Will.Deacon@arm.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=nico@fluxnic.net \ --cc=sam@ravnborg.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.