On 11/29/24 2:15 AM, Stefan Schulze Frielinghaus wrote:
Ping.
On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
This is a follow-up to
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663238.html
The primary changes are about error handling and documentation updates.
Now, we error out whenever a hard register constraint is used more than
once across an alternative for outputs or inputs. For example, the
following is allowed for register asm
register int y __asm__ ("0") = x;
__asm__ ("" : "=r" (y) : "0" (y), "r" (y));
and the analogue for hard register constraints
int y = x;
__asm__ ("" : "={0}" (y) : "0" (y), "{0}" (y)); // invalid
is rejected.
Furthermore, for hard register constraints we fail if an output object
is used more than once as e.g.
int x;
asm ("" : "=r" (x), "={1}" (x)); // rejected
although
int x;
asm ("" : "=r" (x), "=r" (x));
is accepted.
Thus, in total the changes make hard register constraints more strict in
order to prevent subtle bugs.
So this really should have gotten more attention many months ago.
Conceptually I see the value in being able to being able to specify a
specific register in an asm. The single register class constraints
found on x86 have effectively given that port that capability, but
others which truly general purpose registers files don't have a good way
to do this stuff.
I think we should look to try and move this forward early in the gcc-16
cycle. You're definitely going to need to update the manual for the new
capability.
I wouldn't be surprised if this doesn't work on reload targets. While I
think we *can* make it work as the right infrastructure is largely in
place, I don't think it's worth the time as reload should be on the
chopping block in a few months. So I think focusing on LRA only is
sensible.
I'm not aware of any reasonable way to easily solve the fixed register
problem. Though conceptually you could defer when fixed registers are
pruned from the register classes. Vlad might have better ideas in that
space.
Do we detect conflicts between a hard register constraint and another
constraint which requires a singleton class? That's going to be an
error I suspect, but curious if it's handled.
Anyway, I'm sure we'll have other details to hash through. Mostly I
wanted to signal that I can see the value in what you're doing and that
we should be looking to move forward with it during the gcc-16 cycle.
jeff
