From: Renlin Li <renlin.li@foss.arm.com>
To: Andrew Pinski <pinskia@gmail.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: Tue, 27 Jun 2017 15:28:00 -0000 [thread overview]
Message-ID: <59527975.1060304@foss.arm.com> (raw)
In-Reply-To: <CA+=Sn1=wkMcNdA_jPE2vg86hYBareyqGOMMQMdxATN21DEviwQ@mail.gmail.com>
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.
> I like the documentation though.
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.
next prev parent reply other threads:[~2017-06-27 15:28 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 [this message]
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
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=59527975.1060304@foss.arm.com \
--to=renlin.li@foss.arm.com \
--cc=James.Greenhalgh@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=pinskia@gmail.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).