From: "H.J. Lu" <hjl.tools@gmail.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Paolo Bonzini <bonzini@gnu.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Jakub Jelinek <jakub@redhat.com>
Subject: Re: PATCH: PR target/39911: The 'z' suffix doesn't work with 16bit integer insn
Date: Mon, 27 Apr 2009 20:28:00 -0000 [thread overview]
Message-ID: <6dc9ffc80904271311v59513297j88e6625db86db465@mail.gmail.com> (raw)
In-Reply-To: <6dc9ffc80904271249x78008f10h34a03ee633492919@mail.gmail.com>
On Mon, Apr 27, 2009 at 12:49 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Apr 27, 2009 at 11:03 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> H.J. Lu wrote:
>>
>>>>>> In fact, operand modifiers are not documented at all except ia64 `%Pn'.
>>>>>>
>>>>>
>>>>> I saw
>>>>>
>>>>> `m'
>>>>> Memory operand. Remember that `m' allows postincrement and
>>>>> postdecrement which require printing with `%Pn' on IA-64.
>>>>> Use `S' to disallow postincrement and postdecrement.
>>>>>
>>>>> Can you tell how to use it from above? I have to find an example for it.
>>>>> Guess where I can find such examples?
>>>>>
>>>>
>>>> I see your point, but if one looks for %z in config/i386/i386.md he gets
>>>>
>>>> ;; 'z' mov%z1 would be movl, movw, or movb depending on the mode of
>>>> ;; operands[1].
>>>>
>>>> which is exactly the definition that Uros is pushing.
>>>>
>>>
>>> There are several problems:
>>>
>>> 1. It is still the part of gcc source. It isn't the user documentation.
>>> Given some out-of-date comments and actual usages in gcc source,
>>> I will take actual usages over some out-of-date comments.
>>> 2. %z is fully implemented and used for x87 insns.
>>> 3. "movq" isn't mentioned.
>>> 4. "movw/movq" never worked on memory operand.
>>>
>>
>> My reasoning for fixing "%z" are:
>> - users found %z in the comment from i386.md and used it exactly in the way
>> as shown there.
>
> I would say actual codes override any out-of-date comments. Whoever
> made the change forgot to update the comments.
>
>> - %z with x87 doesn not give the suffix as mentioned in the comment above.
>
> %z with x87 insns works for all operands as far as back to gcc 2.95.2.1.
>
>> - there were separate bugreports for ICEs in print_operand with QImode
>> operands and DImode operands. There were reports for wrong HImode suffix for
>> memory operands as well as DImode memory operands. Actually, everything that
>> could go wrong went wrong and these bugreports shows the pattern of uses for
>> %z - also for DImode, even if "movq" is not mentioned.
>>
>> Users are expecting %z to give "q,l,w,b" consistently for register and
>
> There are no working codes which use %z on memory operand with
> integer insns. Otherwise, we won't have this problem.
>
>> memory operands. Regarding x87, not even glibc took the opportunity to use
>> fistp%z in mathinline.h [1].
>
> That shows %z may be useful. We really don't know there are no source
> codes which use %z on x87 insns. Since %z has been working with
> x87 insns for a long time, you won't see any gcc bug reports on this.
>
>> The decision to "break" (?) existing code for x87 was done on these usage
>> patterns. %z modifier was always PITA, so let's give users what they want
>> and let's document the correct usage. And that is %z for all integer and %Z
>
> I don't think the "correct" usage should be determined by some out-of-date
> comments in gcc source codes. There are much more %z usages on x87
> than %z on integer insns in gcc source.
>
>> for FP insns.
>>
>
> When I am using gcc, I simply can't use %z on memory operand with
> integer insns since it doesn't work with gcc ...., 4.1, 4,2, 4,3, 4.4. Breaking
> %z on x87 insns in gcc 4.5 will provide very little benefit for gcc users and
> may cause compatibility issues.
>
I checked the history on i386.c. %z works on x87 insns as far as back
to the initial version on gcc.gnu.org in 1992 and %z never worked on
memory operand with integer insns. I don't believe we should break
%z now. We should use %Z to support integer insns.
--
H.J.
next prev parent reply other threads:[~2009-04-27 20:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-26 20:47 H.J. Lu
2009-04-27 12:16 ` Uros Bizjak
2009-04-27 13:58 ` H.J. Lu
2009-04-27 14:11 ` Paolo Bonzini
2009-04-27 14:17 ` H.J. Lu
2009-04-27 15:23 ` Paolo Bonzini
2009-04-27 16:24 ` H.J. Lu
2009-04-27 16:36 ` Paolo Bonzini
2009-04-27 16:37 ` Paolo Bonzini
2009-04-27 16:49 ` H.J. Lu
2009-04-27 19:04 ` Uros Bizjak
2009-04-27 19:59 ` H.J. Lu
2009-04-27 20:28 ` H.J. Lu [this message]
2009-04-27 20:37 ` Uros Bizjak
2009-04-27 20:56 ` H.J. Lu
2009-04-27 21:12 ` Uros Bizjak
2009-04-27 21:19 ` H.J. Lu
2009-04-28 16:46 ` H.J. Lu
2009-04-28 17:25 ` Uros Bizjak
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=6dc9ffc80904271311v59513297j88e6625db86db465@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=ubizjak@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).