Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 07/20/16 22:04, Jeff Law wrote:
> On 06/22/2016 02:48 PM, Bernd Edlinger wrote:
>> On 06/22/16 21:51, Jeff Law wrote:
>>> On 06/19/2016 07:25 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> ping...
>>>>
>>>> As this discussion did not make any progress, I just attached
>>>> the latest version of my patch with the the changes that
>>>> Vladimir proposed.
>>>>
>>>> Boot-strapped and reg-tested again on x86_64-linux-gnu.
>>>> Is it OK for the trunk?
>>> Well, I don't think we've got any kind of consensus on whether or not
>>> this is reasonable or not.
>>>
>>> The fundamental issue is that "X" is supposed to accept anything,
>>> literally anything.  That implies it's really the downstream users of
>>> those operands that are broken.
>>>
>>
>> Hmm...
>>
>> I think it must be pretty easy to write something in a .md file with the
>> X constraint that ends up in an ICE, right?
> Probably not terribly hard.
>
>>
>> But in an .md file we have much more control on what happens.
>> That's why I did not propose to change the meaning of "X" in .md files.
> We have control over RTL generation, operand predicates and the like.
> And those are how we control things like combine.
>
>>
>> And we only have problems with asm statements that use "X" constraints.
> But I'd disagree.  I think we could easily have problems with "X"
> constraints in the MD file.  But the most common uses of "X" probably
> don't try to refer to that operand in the output string and use good
> predicates.
>
> And that's one of the key differences here.  In an MD file the operand
> predicate has to pass -- that's not the case in an ASM.  The operand
> predicate allows the backend to prevent all kinds of things from showing
> up.
>
>>
>> But I think we have a use case where "X" means really more possible
>> registers (i.e. includes ss2, mmx etc.) than "g" (only general
>> registers).  Otherwise, in the test cases of pr59155 we would not
>> have any benefit for using "+X" instead of "+g" or "+r".
>>
>> Does that sound reasonable?
> If it's the case that the real benefit of +X is that it's allowing more
> registers, then that argues that the backend ought to be providing
> another (larger) register class.
>

X allows more different registers than r, and it is already documented.
In the cases where it is already used, the patch should not break
anything.  I would not understand, why we should forbid the use of X and
waste another letter of the alphabet for a slightly modified version
of X.



Bernd.