From: Jiufu Guo <guojiufu@linux.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org,
bergner@linux.ibm.com
Subject: Re: [PATCH] report message for operator %a on unaddressible exp
Date: Tue, 14 May 2024 10:49:17 +0800 [thread overview]
Message-ID: <h484jb1cdle.fsf@genoa.aus.stglabs.ibm.com> (raw)
In-Reply-To: <20240513110322.GD19790@gate.crashing.org> (Segher Boessenkool's message of "Mon, 13 May 2024 06:03:22 -0500")
Hi,
Thanks for your helpful comments!
Segher Boessenkool <segher@kernel.crashing.org> writes:
> Hi!
>
> On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote:
>> For PR96866, when gcc print asm code for modifier "%a" which requires
>> an address operand,
>
> It requires a *memory* operand, and it outputs its address. This is a
> generic modifier btw (not rs6000).
Oh, yeap. it outputs the operands's address. I would update words like:
which requires an addressable operand.
>
>> while the operand is with the constraint "X" which
>> allow non-address form. An error message would be reported to indicate
>> the invalid asm operands.
>
> "non-address form"? Every mem has an address.
>
> But 'X' is not memory. What is it at all? Why do we use that when you
> *have to* have mem here?
"X" allows any thing. This is the reason why the code is *invalid*.
Other constraints("r/m") should be better than "X" for "%a".
>
> The code you add that tests for address_operand looks wrong. I would
> expect it to test the operand is memory, instead :-)
I understand your concern. While there is a tricky work:
before invoking print_operand_address/output_address, the orignal
operand (which would be 'mem') is stripped to it's address.
So, 'address_operand' is tested for print_operand_address is targets.
While I also wonder if "address_operand" is really needed. Because
under the condition:
```
else if (SYMBOL_REF_P (x) || GET_CODE (x) == CONST
|| GET_CODE (x) == LABEL_REF)
{
```
'x' is already known, it only could be: SYMBOL_REF/LABEL_REF or CONST.
I would update the patch for this.
Thanks for your comments.
BR,
Jeff(Jiufu) Guo
>
>
> Segher
prev parent reply other threads:[~2024-05-14 2:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 2:57 Jiufu Guo
2024-05-13 6:27 ` Kewen.Lin
2024-05-14 3:00 ` Jiufu Guo
2024-05-14 3:15 ` Kewen.Lin
2024-05-14 3:32 ` Jiufu Guo
2024-05-14 9:11 ` Segher Boessenkool
2024-05-14 9:40 ` Jiufu Guo
2024-05-14 9:20 ` Segher Boessenkool
2024-05-14 9:53 ` Jiufu Guo
2024-05-14 10:43 ` Segher Boessenkool
2024-05-15 2:34 ` Jiufu Guo
2024-05-16 6:56 ` Jiufu Guo
2024-05-16 14:55 ` Segher Boessenkool
2024-05-13 11:03 ` Segher Boessenkool
2024-05-14 2:49 ` Jiufu Guo [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=h484jb1cdle.fsf@genoa.aus.stglabs.ibm.com \
--to=guojiufu@linux.ibm.com \
--cc=bergner@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linkw@gcc.gnu.org \
--cc=segher@kernel.crashing.org \
/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).