This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]