public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.

      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).