RISC-V GCC RFC: "-mstrict-align" argument, and unaligned access tuning

[Palmer Dabbelt]

As Alex suggested a little while ago, we're going to start bringing up
toolchain interface changes on the mailing list for discussion before they go
upstream, so we can avoid any interface incompatibilities. There's a pull
request open right now that implements (with a bug, so it won't be merged for a
bit) the "-mstrict-align" argument to GCC.

https://github.com/riscv/riscv-gcc/pull/59

Passing "-mstrict-align" indicates that the target platform disallows unaligned
accesses. This is designed for machine mode software that can't handle
unaligned accesses via a trap and isn't running on hardware that supports
unaligned accesses. This argument already exists on PowerPC and has the same
behavior.

In addition to "-mstrict-align" the idea of unaligned access tuning came up.
We've decided to have the "-mtune" argument control unaligned access tuning
(ie, "is unaligned access fast" as opposed to "is unaligned access legal").
"-mtune=rocket" would mark unaligned accesses as slow, while "-Os" would mark
them as fast (as that generates smaller code).

I think this is a pretty straight-forward change, which is probably a good
thing because it's our first time trying to RFC interface changes.

Does anyone have any comments?

[Andrew Waterman]

Stefan O'Rear has suggested that -Os shouldn't connote that misaligned
accesses are fast, because the performance cliff is so steep that
reduced code size doesn't justify using them. (Typically, the
tradeoffs -Os makes are quite a bit more mild.) The suggestion was
that only -mtune would govern whether misaligned accesses are fast.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/mhng-f02fa971-9ca5-4691-a64f-f88aa96855a3%40palmer-si-x1c4.

[Alex Bradbury]

On 3 April 2017 at 19:30, Palmer Dabbelt <pal...@sifive.com> wrote:
> As Alex suggested a little while ago, we're going to start bringing up
> toolchain interface changes on the mailing list for discussion before they go
> upstream, so we can avoid any interface incompatibilities.

Thanks Palmer!

> There's a pull
> request open right now that implements (with a bug, so it won't be merged for a
> bit) the "-mstrict-align" argument to GCC.
>
> https://github.com/riscv/riscv-gcc/pull/59
>
> Passing "-mstrict-align" indicates that the target platform disallows unaligned
> accesses. This is designed for machine mode software that can't handle
> unaligned accesses via a trap and isn't running on hardware that supports
> unaligned accesses. This argument already exists on PowerPC and has the same
> behavior.

Do we want to document and support -mnostrict-align while we're at it
as well? e.g. if I specify -mcpu=fe310 but I actually want to compile
my code assuming a misaligned access handler is present. For the
record, the ARM spellings of this functionality are
<https://developer.arm.com/docs/dui0774/latest/compiler-command-line-options/-munaligned-access-mno-unaligned-access>
-munaligned-access and -mno-unaligned-access.

> In addition to "-mstrict-align" the idea of unaligned access tuning came up.
> We've decided to have the "-mtune" argument control unaligned access tuning
> (ie, "is unaligned access fast" as opposed to "is unaligned access legal").
> "-mtune=rocket" would mark unaligned accesses as slow, while "-Os" would mark
> them as fast (as that generates smaller code).

I agree that having the modelled cost of unaligned access controlled
by -mtune makes sense, and the suggestion from Stefan that -Os
refrains from indicating unaligned access as fast also seems
reasonable. I think the details of exactly which tuning options are
triggered by different optimisation levels is going to vary between
compilers, and between releases of the same compiler, so that's
probably not a detail that we all need to agree on. There's no point
being arbitrarily different of course.

Best,

Alex

[Bruce Hoult]

Enabling the optimizer to generate unaligned accesses where none were before where they are supported but very slow seems more like a -Oz feature than -Os.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

[Michael Clark]

I strongly agree with not changing alignment rules for -Os.

Slow misaligned access is practically equivalent to no misaligned accesses for most code as I believe slow misaligned accesses essentially just makes __attribute__((packed)) and various pointer dereferences legal which tend to be very rare in portable code, and slow misaligned accesses is the default even for platforms that allow misaligned accesses, including when using -Os.

I think alignment rules should stay tied to -mstrict-align and -mtune options as per the first part of the proposal. Changing alignment rules with -Os could lead to hard to track down performance issues. -Os is very commonly used as an alternative to -O3 for embedded environments and should also be seen as a performance optimisation.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2B%2B6G0CwnstorcYC%2BrEedOssZ3K%3DDBpGdsdOTqz%2BS%2Bmp3FntnQ%40mail.gmail.com.

[Stefan O'Rear]

On Mon, Apr 3, 2017 at 1:05 PM, Alex Bradbury <a...@asbradbury.org> wrote:
> On 3 April 2017 at 19:30, Palmer Dabbelt <pal...@sifive.com> wrote:
>> As Alex suggested a little while ago, we're going to start bringing up
>> toolchain interface changes on the mailing list for discussion before they go
>> upstream, so we can avoid any interface incompatibilities.

(If it wasn't already clear from the ticket, I am generally +1 on this)

> Do we want to document and support -mnostrict-align while we're at it
> as well? e.g. if I specify -mcpu=fe310 but I actually want to compile
> my code assuming a misaligned access handler is present. For the
> record, the ARM spellings of this functionality are
> <https://developer.arm.com/docs/dui0774/latest/compiler-command-line-options/-munaligned-access-mno-unaligned-access>
> -munaligned-access and -mno-unaligned-access.

My take here, which might be completely off base, is that since the
RISC-V spec requires unaligned access (and RDCYCLE/RDTIME/RDINSTRET),
the fact that freedom-e-sdk doesn't install handlers for unaligned
access and timer CSRs is a bug in freedom-e-sdk and should be fixed
there instead of in gcc.

The FE310 considered in isolation is not a conforming system; if you
choose to use the FE310 without the HiFive1 BSP you have a choice
between implementing a trap handler to make it a conforming system
(and this should be conspicuously noted in product documentation), or
telling gcc to target a nonconforming system with -mstrict-align.

(Aside, in general all options should be invertable, but if you're
using -mstrict-align -mno-strict-align that probably indicates that
your Makefile needs refactoring more than anything else.)

-s

[Alex Bradbury]

On 4 April 2017 at 05:58, Stefan O'Rear <sor...@gmail.com> wrote:
> On Mon, Apr 3, 2017 at 1:05 PM, Alex Bradbury <a...@asbradbury.org> wrote:
>> On 3 April 2017 at 19:30, Palmer Dabbelt <pal...@sifive.com> wrote:
>>> As Alex suggested a little while ago, we're going to start bringing up
>>> toolchain interface changes on the mailing list for discussion before they go
>>> upstream, so we can avoid any interface incompatibilities.
>
> (If it wasn't already clear from the ticket, I am generally +1 on this)
>
>> Do we want to document and support -mnostrict-align while we're at it
>> as well? e.g. if I specify -mcpu=fe310 but I actually want to compile
>> my code assuming a misaligned access handler is present. For the
>> record, the ARM spellings of this functionality are
>> <https://developer.arm.com/docs/dui0774/latest/compiler-command-line-options/-munaligned-access-mno-unaligned-access>
>> -munaligned-access and -mno-unaligned-access.
>
> My take here, which might be completely off base, is that since the
> RISC-V spec requires unaligned access (and RDCYCLE/RDTIME/RDINSTRET),
> the fact that freedom-e-sdk doesn't install handlers for unaligned
> access and timer CSRs is a bug in freedom-e-sdk and should be fixed
> there instead of in gcc.
>
> The FE310 considered in isolation is not a conforming system; if you
> choose to use the FE310 without the HiFive1 BSP you have a choice
> between implementing a trap handler to make it a conforming system
> (and this should be conspicuously noted in product documentation), or
> telling gcc to target a nonconforming system with -mstrict-align.

There seems to be a desire to support systems that implement only a
subset of functionality in the existing 'base' spec and don't provide
trap handlers. Unfortunately this further fractures the RISC-V
ecosystem - I've struggled to get an answer for the motivation behind
this <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/I3og57V1aHg/UbYKApQKBwAJ>.
To quote the key paragraph:

"""
As I think my emails make clear, I personally am concerned about the
downside to further subsetting the base RISC-V ISA. What I'm
struggling to understand is the upside that you see? Providing default
trap routines for misaligned access and transparently handling
rdcycle/rdtime/rdinstret is surely at worst just going to mean RISC-V
code size grows a couple of hundred bytes in a naive comparison vs
ARM. Those bytes can always be clawed back with a simple compiler flag
if someone feels happy moving away from the common base.
"""

Best,

Alex

[Stefan O'Rear]

On Tue, Apr 4, 2017 at 12:56 AM, Alex Bradbury <a...@asbradbury.org> wrote:
> """
> As I think my emails make clear, I personally am concerned about the
> downside to further subsetting the base RISC-V ISA. What I'm
> struggling to understand is the upside that you see? Providing default
> trap routines for misaligned access and transparently handling
> rdcycle/rdtime/rdinstret is surely at worst just going to mean RISC-V
> code size grows a couple of hundred bytes in a naive comparison vs
> ARM. Those bytes can always be clawed back with a simple compiler flag
> if someone feels happy moving away from the common base.
> """

That's precisely why I'm saying that nonconformingness must be
targeted explicitly and never be automatic from a -mcpu choice.

-s