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