From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] arm: Switch to -mno-unaligned-access when supported by the compiler
Date: Tue, 11 Feb 2014 18:11:11 +0100 [thread overview]
Message-ID: <20140211181111.16b1791a@lilith> (raw)
In-Reply-To: <yw1x38jpa9a9.fsf@unicorn.mansr.com>
Hi M?ns,
On Tue, 11 Feb 2014 16:44:46 +0000, M?ns Rullg?rd <mans@mansr.com>
wrote:
> Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
>
> > Hi M?ns,
> >
> > On Tue, 11 Feb 2014 15:33:09 +0000, M?ns Rullg?rd <mans@mansr.com>
> > wrote:
> >
> >> The problem is that the current settings do
> >> the exact opposite. By using -munaligned-access by default, you are
> >> asking the compiler to go ahead and do whatever it thinks is best, which
> >> is sometimes to perform an intentional unaligned access. Exactly when
> >> this will happen is largely impossible to predict.
> >
> > The -munaligned-access option does *not* "[ask] the compiler to go
> > ahead and do whatever it thinks is best", it tells it to use direct
> > native accesses when unaligned accesses are required, as opposed to
> > splitting unaligned accesses into smaller but aligned aligned native
> > accesses, which is what you get with -mno-unaligned-access.
>
> The flag does both of those things. It even gives the compiler
> permission to merge multiple adjacent accesses into a single wider one.
Both of which two things exactly?
Besides, the only place where we saw it merge adjacent accesses into a
wider one is in some cases of array initialization which are documented
in doc/README.arm-unaligned-accesses.
> >> To get the behaviour you desire, the code should be compiled with
> >> -mno-unaligned-access. This tells the compiler to _never_ automatically
> >> perform an unaligned memory access. If it thinks an address might be
> >> unaligned, it will split the access.
> >
> > This shows that you really have not read my argument, in which I *did*
> > explain why we tell the compiler *not* to split unaligned accesses into
> > smaller correctly aligned accesses, i.e., why -munaligned-access is
> > used.
>
> I have read what you call your argument. Unfortunately for you, it is
> based on false premises, and as such any conclusions you arrive at are
> incorrect.
(you have asked someone else not to be condescending. I, in turn, ask
you to stop being insulting.)
If you have read my argument, then I assume you have understood that the
point of it is to detect uncontrolled unaligned accesses; however, your
rebuttal apparently misses this point, as it proposes to *prevent*
detection of such unaligned accesses.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2014-02-11 17:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 17:05 [U-Boot] [PATCH v2] arm: Switch to -mno-unaligned-access when supported by the compiler Tom Rini
2014-02-04 17:35 ` Måns Rullgård
2014-02-10 9:24 ` Albert ARIBAUD
2014-02-10 13:21 ` Tom Rini
2014-02-10 14:57 ` Albert ARIBAUD
2014-02-10 15:14 ` Måns Rullgård
2014-02-10 15:40 ` Måns Rullgård
2014-02-10 16:12 ` Albert ARIBAUD
2014-02-10 16:21 ` Måns Rullgård
2014-02-10 16:24 ` Tom Rini
2014-02-10 17:26 ` Albert ARIBAUD
2014-02-10 18:54 ` Wolfgang Denk
2014-02-10 21:26 ` Tom Rini
2014-02-10 22:17 ` Wolfgang Denk
2014-02-10 22:28 ` Tom Rini
2014-02-11 8:19 ` Wolfgang Denk
2014-02-11 12:37 ` Måns Rullgård
2014-02-11 14:43 ` Wolfgang Denk
2014-02-11 15:33 ` Måns Rullgård
2014-02-11 16:37 ` Albert ARIBAUD
2014-02-11 16:44 ` Måns Rullgård
2014-02-11 17:11 ` Albert ARIBAUD [this message]
2014-02-11 17:21 ` Albert ARIBAUD
2014-02-12 14:35 ` Tom Rini
2014-02-12 16:19 ` Albert ARIBAUD
2014-02-17 15:45 ` Tom Rini
2014-02-17 15:55 ` Albert ARIBAUD
2014-02-11 18:18 ` Wolfgang Denk
2014-02-11 18:21 ` Måns Rullgård
2014-02-11 8:44 ` Albert ARIBAUD
2014-02-12 14:25 ` Tom Rini
2014-02-12 15:51 ` Wolfgang Denk
2014-02-10 15:21 ` Tom Rini
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=20140211181111.16b1791a@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/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 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.