From: Andrew Pinski <pinskia@gmail.com>
To: Renlin Li <renlin.li@foss.arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
James Greenhalgh <James.Greenhalgh@arm.com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: [RFC][AARCH64]Add 'r' integer register operand modifier. Document the common asm modifier for aarch64 target.
Date: Thu, 31 Aug 2017 18:54:00 -0000 [thread overview]
Message-ID: <CA+=Sn1kqVHOsu-MA-74wishG-uHnB01-jO2gWzMHStTqE5H5ZQ@mail.gmail.com> (raw)
In-Reply-To: <59A8406F.9040800@foss.arm.com>
On Thu, Aug 31, 2017 at 9:59 AM, Renlin Li <renlin.li@foss.arm.com> wrote:
> Hi all,
>
> This is a split patch from a discussion here:
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00289.html
>
> It contains the document part only.
> It clarify the behavior when no modifier is used for register operand.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
>
> 'H' modifier is added for TImode register pair case.
>
> It only documents the most common cases I can think of. Any other
> suggestions are welcome.
>
> Is Okay to trunk?
From my point of view this looks good.
Thanks,
Andrew
>
> Regards,
> Renlin
>
>
> gcc/ChangeLog:
>
> 2017-08-31 Renlin Li <renlin.li@arm.com>
>
> PR target/63359
> * doc/extend.texi (AArch64Operandmodifers): New section.
>
>
> On 27/06/17 18:19, Renlin Li wrote:
>>
>> Hi Andrew,
>>
>> On 27/06/17 17:11, Andrew Pinski wrote:
>>>
>>> On Tue, Jun 27, 2017 at 8:27 AM, Renlin Li <renlin.li@foss.arm.com>
>>> wrote:
>>>>
>>>> Hi Andrew,
>>>>
>>>> On 25/06/17 22:38, Andrew Pinski wrote:
>>>>>
>>>>>
>>>>> On Tue, Jun 6, 2017 at 3:56 AM, Renlin Li <renlin.li@foss.arm.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> In this patch, a new integer register operand modifier 'r' is added.
>>>>>> This
>>>>>> will use the
>>>>>> proper register name according to the mode of corresponding operand.
>>>>>>
>>>>>> 'w' register for scalar integer mode smaller than DImode
>>>>>> 'x' register for DImode
>>>>>>
>>>>>> This allows more flexibility and would meet people's expectations.
>>>>>> It will help for ILP32 and LP64, and big-endian case.
>>>>>>
>>>>>> A new section is added to document the AArch64 operand modifiers which
>>>>>> might
>>>>>> be used in inline assembly. It's not an exhaustive list covers every
>>>>>> modifier.
>>>>>> Only the most common and useful ones are documented.
>>>>>>
>>>>>> The default behavior of integer operand without modifier is clearly
>>>>>> documented
>>>>>> as well. It's not changed so that the patch shouldn't break anything.
>>>>>>
>>>>>> So with this patch, it should resolve the issues in PR63359.
>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
>>>>>>
>>>>>>
>>>>>> aarch64-none-elf regression test Okay. Okay to check in?
>>>>>
>>>>>
>>>>>
>>>>> I think 'r' modifier is very fragile and can be used incorrectly and
>>>>> wrong in some cases really..
>>>>
>>>>
>>>>
>>>> The user could always (or be encouraged to) opt to a strict register
>>>> modifier to enforce consistent behavior in all cases.
>>>>
>>>> I agree the flexibility might bring unexpected behavior in corner cases.
>>>> Do you have any examples to share off the top of your head? So that we
>>>> can
>>>> discuss the benefit and pitfalls, and decide to improve the patch or
>>>> withdraw it.
>>>
>>>
>>> One thing is TImode is missing. I have an use case of __int128_t
>>> inside inline-asm.
>>> For me %r and TImode would produce "x0, x1". This is one of the
>>> reasons why I said it is fragile.
>>>
>>
>> This is true. Actually, I intended to make 'r' only handle the simplest
>> single
>> integer register case.
>> So that people won't believe it's a magic thing which could handle
>> everything.
>> I could improve the description about 'r' to clearly explain it's
>> limitation.
>>
>> For TImode integer data, if 'r' is used, it will error
>> "invalid 'asm': invalid operand mode for register modifier 'r'"
>>
>>>>
>>>>> I like the documentation though.
>>>
>>>
>>> As an aside %H is not documented here. Noticed it because I am using
>>> %H with TImode.
>>
>>
>> For the document as well, I only document those most common ones which
>> might be used in
>> inline assembly. It's good to know more use cases.
>> I could add 'H' into the document.
>>
>> Regards,
>> Renlin
>>
>>>
>>> Thanks,
>>> Andrew
>>>
>>>>
>>>> Thanks,
>>>> Renlin
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>>>
>>>>>> gcc/ChangeLog:
>>>>>>
>>>>>> 2017-06-06 Renlin Li <renlin.li@arm.com>
>>>>>>
>>>>>> PR target/63359
>>>>>> * config/aarch64/aarch64.c (aarch64_print_operand): Add 'r'
>>>>>> modifier.
>>>>>> * doc/extend.texi (AArch64Operandmodifiers): New section.
prev parent reply other threads:[~2017-08-31 17:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 10:56 Renlin Li
2017-06-25 21:38 ` Andrew Pinski
2017-06-27 15:28 ` Renlin Li
2017-06-27 16:11 ` Andrew Pinski
2017-06-27 17:19 ` Renlin Li
2017-08-31 17:45 ` Renlin Li
2017-08-31 18:54 ` Andrew Pinski [this message]
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='CA+=Sn1kqVHOsu-MA-74wishG-uHnB01-jO2gWzMHStTqE5H5ZQ@mail.gmail.com' \
--to=pinskia@gmail.com \
--cc=James.Greenhalgh@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=renlin.li@foss.arm.com \
/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 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).