* riscv32 : -mno-strict-align has no effect
@ 2020-01-20 1:39 Alex Rocha Prado
2020-01-20 7:17 ` Stefan Ring
2020-01-20 22:24 ` Jim Wilson
0 siblings, 2 replies; 6+ messages in thread
From: Alex Rocha Prado @ 2020-01-20 1:39 UTC (permalink / raw)
To: gcc-help
Hi,
Given the test source code below (example):
void foo(void)
{
*((int*) 0x1001) = *((int*) 0x2003);
}
I have run to compilations using the following command lines on gcc 9.2.0:
$ riscv32-unknown-elf-gcc -mno-strict-align -O2 -S -mabi=ilp32 -march=rv32i
and
$ riscv32-unknown-elf-gcc -mstrict-align -O2 -S -mabi=ilp32 -march=rv32i
It happens that both line generate the same code, so there is some kind of problem with gcc, correct ?
Regards,
Alex Rocha Prado
Public information
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: riscv32 : -mno-strict-align has no effect
2020-01-20 1:39 riscv32 : -mno-strict-align has no effect Alex Rocha Prado
@ 2020-01-20 7:17 ` Stefan Ring
2020-01-20 12:52 ` [EXT] " Alex Rocha Prado
2020-01-20 22:24 ` Jim Wilson
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Ring @ 2020-01-20 7:17 UTC (permalink / raw)
To: Alex Rocha Prado; +Cc: gcc-help
On Mon, Jan 20, 2020 at 2:39 AM Alex Rocha Prado <alex.prado@nxp.com> wrote:
>
> Given the test source code below (example):
>
> void foo(void)
> {
> *((int*) 0x1001) = *((int*) 0x2003);
> }
> [...]
> It happens that both line generate the same code, so there is some kind of problem with gcc, correct ?
I don't think this is a good example, as the compiler can see from the
constants that the addresses are not aligned.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [EXT] Re: riscv32 : -mno-strict-align has no effect
2020-01-20 7:17 ` Stefan Ring
@ 2020-01-20 12:52 ` Alex Rocha Prado
0 siblings, 0 replies; 6+ messages in thread
From: Alex Rocha Prado @ 2020-01-20 12:52 UTC (permalink / raw)
To: Stefan Ring; +Cc: gcc-help
Hi Stefan,
I am sorry, I did not understand why the example is not a good one. My intention is exactly making sure the compiler notice it is an unaligned access and by using -mno-strict-align it generate regular lw/st instructions (since the hardware can handle it nicely).
Regards,
Alex
-----Original Message-----
From: Stefan Ring <stefanrin@gmail.com>
Sent: Monday, January 20, 2020 4:17 AM
To: Alex Rocha Prado <alex.prado@nxp.com>
Cc: gcc-help@gcc.gnu.org
Subject: [EXT] Re: riscv32 : -mno-strict-align has no effect
Caution: EXT Email
On Mon, Jan 20, 2020 at 2:39 AM Alex Rocha Prado <alex.prado@nxp.com> wrote:
>
> Given the test source code below (example):
>
> void foo(void)
> {
> *((int*) 0x1001) = *((int*) 0x2003); } [...] It happens that both
> line generate the same code, so there is some kind of problem with gcc, correct ?
I don't think this is a good example, as the compiler can see from the constants that the addresses are not aligned.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: riscv32 : -mno-strict-align has no effect
2020-01-20 1:39 riscv32 : -mno-strict-align has no effect Alex Rocha Prado
2020-01-20 7:17 ` Stefan Ring
@ 2020-01-20 22:24 ` Jim Wilson
2020-01-21 8:20 ` Henri Cloetens
1 sibling, 1 reply; 6+ messages in thread
From: Jim Wilson @ 2020-01-20 22:24 UTC (permalink / raw)
To: Alex Rocha Prado; +Cc: gcc-help
On Sun, Jan 19, 2020 at 5:39 PM Alex Rocha Prado <alex.prado@nxp.com> wrote:
> It happens that both line generate the same code, so there is some kind of problem with gcc, correct ?
-mno-strict-align does have an effect, but it isn't very useful. The
problem here is that gcc knows that the target does not support
unaligned accesses, so it is refusing to produce them even when
-mno-strict-align is used. Unfortunately, the only supported target
with unaligned accesses is the fake -mtune=size target, which exists
only for use with the -Os option. So if you use -mtune=size
-mno-strict-align you can get the result you probably want. However,
I wouldn't recommend doing that, as I can't guarantee that -mtune=size
will work the same in the future. If you do have a target that
supports unaligned accesses, then you should add support for that
target to gcc, and then using -mtune=yourtarget -mno-strict-align will
work. If you don't have a target that supports unaligned accesses,
then why do you want the compiler to emit broken code?
This alignment stuff should probably be rewritten at some point to
make the usage of the options more obvious, but I have no idea when
that will happen. At the moment, there is no incentive, as gcc
doesn't have support for any RISC-V targets that support unaligned
accesses.
Jim
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: riscv32 : -mno-strict-align has no effect
2020-01-20 22:24 ` Jim Wilson
@ 2020-01-21 8:20 ` Henri Cloetens
2020-01-21 10:36 ` Henri Cloetens
0 siblings, 1 reply; 6+ messages in thread
From: Henri Cloetens @ 2020-01-21 8:20 UTC (permalink / raw)
To: gcc-help
Hello,
I dont know why you want to work on a target with unaligned accesses,
but there are
real ones that have this. I am working on a custom processor, and it has
it. As far as
I know - not sure, have to check - there are also other target that have it.
Best Regards,
Henri.
On 01/20/2020 11:23 PM, Jim Wilson wrote:
> On Sun, Jan 19, 2020 at 5:39 PM Alex Rocha Prado <alex.prado@nxp.com> wrote:
>> It happens that both line generate the same code, so there is some kind of problem with gcc, correct ?
> -mno-strict-align does have an effect, but it isn't very useful. The
> problem here is that gcc knows that the target does not support
> unaligned accesses, so it is refusing to produce them even when
> -mno-strict-align is used. Unfortunately, the only supported target
> with unaligned accesses is the fake -mtune=size target, which exists
> only for use with the -Os option. So if you use -mtune=size
> -mno-strict-align you can get the result you probably want. However,
> I wouldn't recommend doing that, as I can't guarantee that -mtune=size
> will work the same in the future. If you do have a target that
> supports unaligned accesses, then you should add support for that
> target to gcc, and then using -mtune=yourtarget -mno-strict-align will
> work. If you don't have a target that supports unaligned accesses,
> then why do you want the compiler to emit broken code?
>
> This alignment stuff should probably be rewritten at some point to
> make the usage of the options more obvious, but I have no idea when
> that will happen. At the moment, there is no incentive, as gcc
> doesn't have support for any RISC-V targets that support unaligned
> accesses.
>
> Jim
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: riscv32 : -mno-strict-align has no effect
2020-01-21 8:20 ` Henri Cloetens
@ 2020-01-21 10:36 ` Henri Cloetens
0 siblings, 0 replies; 6+ messages in thread
From: Henri Cloetens @ 2020-01-21 10:36 UTC (permalink / raw)
To: gcc-help
Hello,
To this regard, again, I read in the "PowerISA_public.v3.0B.pdf" ,
page 25, (quote):
> Some instructions require their storage operands to
> have certain alignments. In addition, alignment may
> affect performance. In general, the best performance is
> obtained when storage operands are aligned.
This clearly states that for PowerPc, not all memory accesses need to be
aligned. If you want a processor with unaligned access, I would recommend
you to check the different types of PowerPc processors.
Best Regards,
Henri.
On 01/21/2020 09:21 AM, Henri Cloetens wrote:
> Hello,
>
> I dont know why you want to work on a target with unaligned accesses,
> but there are
> real ones that have this. I am working on a custom processor, and it
> has it. As far as
> I know - not sure, have to check - there are also other target that
> have it.
>
> Best Regards,
>
> Henri.
>
>
> On 01/20/2020 11:23 PM, Jim Wilson wrote:
>> On Sun, Jan 19, 2020 at 5:39 PM Alex Rocha Prado <alex.prado@nxp.com>
>> wrote:
>>> It happens that both line generate the same code, so there is some
>>> kind of problem with gcc, correct ?
>> -mno-strict-align does have an effect, but it isn't very useful. The
>> problem here is that gcc knows that the target does not support
>> unaligned accesses, so it is refusing to produce them even when
>> -mno-strict-align is used. Unfortunately, the only supported target
>> with unaligned accesses is the fake -mtune=size target, which exists
>> only for use with the -Os option. So if you use -mtune=size
>> -mno-strict-align you can get the result you probably want. However,
>> I wouldn't recommend doing that, as I can't guarantee that -mtune=size
>> will work the same in the future. If you do have a target that
>> supports unaligned accesses, then you should add support for that
>> target to gcc, and then using -mtune=yourtarget -mno-strict-align will
>> work. If you don't have a target that supports unaligned accesses,
>> then why do you want the compiler to emit broken code?
>>
>> This alignment stuff should probably be rewritten at some point to
>> make the usage of the options more obvious, but I have no idea when
>> that will happen. At the moment, there is no incentive, as gcc
>> doesn't have support for any RISC-V targets that support unaligned
>> accesses.
>>
>> Jim
>>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-21 10:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-20 1:39 riscv32 : -mno-strict-align has no effect Alex Rocha Prado
2020-01-20 7:17 ` Stefan Ring
2020-01-20 12:52 ` [EXT] " Alex Rocha Prado
2020-01-20 22:24 ` Jim Wilson
2020-01-21 8:20 ` Henri Cloetens
2020-01-21 10:36 ` Henri Cloetens
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 read-only IMAP folder(s) and NNTP newsgroup(s).