This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch AArch64] Fix extended register width


On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 30/09/14 21:30, Eric Christopher wrote:
>> 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.
>>
>
> Agreed.  We're already working on it...

I assume you mean 'working on the documentation' ?

David

>
> R.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]