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.
