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


> Are you suggesting we are free to change asm statement behaviors
> as long as they aren't mentioned in gcc.info? What is difference
> between a feature which we failed to document properly and a
> feature purely internal to gcc?

In any case we have to use our judgement about what code is going to
break when we change undocumented details.  In some case, we may like to
be more free about how to make such a feature can be most useful to the
users in preparation to it being documented.  This way, _when and if_ we
document it, it will behave as it has existed for a while.

In this particular case, there are two possible definitions.  For one of
it, we do not know about uses in the wild, but of course there may be
proprietary uses.  The other is what is documented in the GCC sources,
despite they actually implement the first, and we have bug reports
suggesting that users had taken the wrong suggestion for the GCC sources.

>> 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.

> I don't think you are telling me that it is OK to change those modifiers
> used by asm statement, except for ia64 `%Pn'.

I do think that operand modifiers are a feature that, right now, can be
considered "almost" internal to gcc.

It does not have to stay this way forever, of course.  To fully solve
the issue, we should document operand modifiers at least in a restricted
form (for example i386 %b could be documented too, it is useful with
setCC) and add the change to the GCC 4.5 changes page.

Paolo


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