On Wed, Jan 15, 2025 at 10:29:03PM -0700, Jeff Law wrote: > > > 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 added some documentation to gcc/doc/extend.texi. Is there some other place I should document this? > > 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. That is a good point. Currently I suspect no. I will have a look. > > 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. Sounds good; thanks for letting me know. Cheers, Stefan
