This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch AArch64] Fix extended register width
- From: Eric Christopher <echristo at gmail dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Carrot Wei <carrot at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Sep 2014 13:30:46 -0700
- Subject: Re: [Patch AArch64] Fix extended register width
- Authentication-results: sourceware.org; auth=none
- References: <CAEe8uECt6oU8EMGZDfDPyPn3tOt+eFQs=DfQmbU0pqmr1uL_ag at mail dot gmail dot com> <CAFqB+Pz20vtXH0xuGOiPvVJ--Br8ogvULXVGHno1GmYWdF7Kfw at mail dot gmail dot com>
On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft
<marcus.shawcroft@gmail.com> wrote:
> On 22 September 2014 19:41, Carrot Wei <carrot@google.com> wrote:
>> Hi
>>
>> The extended register width in add/adds/sub/subs/cmp instructions is
>> not always the same as target register, it depends on both target
>> register width and extension type. But in current implementation the
>> extended register width is always the same as target register. We have
>> noticed it can generate following wrong assembler code when compiled
>> an internal application,
>>
>> add x2, x20, x0, sxtw 3
>>
>> The correct assembler should be
>>
>> add x2, x20, w0, sxtw 3
>
Hi Marcus,
> Hi,
>
> The assembler deliberately accepts the first form as a programmer
> convenience. Given the above example:
>
I've been doing some reading of the ARM-v8 ARM and the language the
ARM uses here for this instruction matches the "shall" and not
"should" language it uses in other locations:
"Is the 32-bit name of the second general-purpose source register,
encoded in the "Rm" field."
This seems to say that a conforming assembler should error on a
non-32bit named register here. As I said, same sort of verbiage used
elsewhere for shall, in "should" cases the ARM is very careful to
spell it out.
Now if we want to change the ARM philosophy here I'm not opposed, but
I think we'd want some more explicit documentation about how/where
things should be more relaxed versus a bunch of "this is convenient to
accept here" stuff. That kind of thing has a tendency to end up in
some pretty fun context sensitive parsing madness.
Thoughts?
-eric
> AARCH64 GAS x.s page 1
>
>
> 1 0000 82CE20AB adds x2, x20, x0, sxtw 3
> 2 0004 82CE20AB adds x2, x20, w0, sxtw 3
>
> Note both forms are correctly assembled. The GAS implementation
> contains code at (or near) tc-aarch64.c:5461 that specifically catches
> the former.
>
> ... therefore I see no need to change the behaviour of gcc.
>
> Cheers
> /Marcus