On 08/04/16 22:27, Jeff Law wrote:
> On 07/21/2016 10:29 AM, Bernd Edlinger wrote:
>>>> 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.
> Doing so essentially allows us to deprecate "X" to used by target
> patterns only -- where what's acceptable is limited by the operand
> predicates. Those limits ultimately protect the rest of the routines
> from having to handle arbitrary RTL.
>
> Meanwhile asms can use the new letter to say "I'll take any register of
> any class". Which is, AFAICT, what's desired here.
>
> jeff
Yes. To be useful it should be a target independent letter.
While "g" implies a general register of class GENERAL_REGS
"X" implies any register of class ALL_REGS.
I have looked for uses of "X" and actually found some of them in glibc:
./sysdeps/powerpc/powerpc64/dl-machine.h:
/* GCC 4.9+ eliminates the branch as dead code, force the odp set
dependency. */
asm ("" : "=r" (value) : "0" (&opd), "X" (opd));
./sysdeps/mach/hurd/i386/init-first.c:
*--newsp = *((int *) __builtin_frame_address (0) + 1);
/* GCC 4.4.6 also wants us to force loading *NEWSP already here. */
asm volatile ("# %0" : : "X" (*newsp));
and same file:
usercode = *((int *) __builtin_frame_address (0) + 1);
/* GCC 4.4.6 also wants us to force loading USERCODE already
here. */
asm volatile ("# %0" : : "X" (usercode));
So in is mostly used for obfuscating the data flow.
The documentation of "g" at md.texi says
@cindex @samp{g} in constraint
@item @samp{g}
Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers.
and "X" says:
@ifset INTERNALS
Any operand whatsoever is allowed, even if it does not satisfy
@code{general_operand}. This is normally used in the constraint of
a @code{match_scratch} when certain alternatives will not actually
require a scratch register.
@end ifset
@ifclear INTERNALS
Any operand whatsoever is allowed.
@end ifclear
The part ifset INTERNALS describes the rules for target patterns,
while the ifclear INTERNALS part describes the rules for asms.
This is exactly what we want. Not saying "except for
registers that are not general registers" is a hint that there
are more registers in the ALL_REGS class. We could make it more
explicit by adding "Including registers that are not general
registers".
And "whatsoever" means anything you can write down at the source code
level IMO.
So I think restricting "X" in asms to this definition while keeping
the current meaning of "X" in target patterns is consistent with the
current documentation and compatible to the current uses of the
"X" constraint elsewhere.
Bernd.
