Re: PATCH: PR target/39911: The 'z' suffix doesn't work with 16bit integer insn

["H.J. Lu" <hjl.tools@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.