Hi! On Sun, May 31, 2026 at 03:32:00PM +0200, Georg-Johann Lay via Gcc wrote: > Am 30.05.26 um 16:48 schrieb Segher Boessenkool: > > Interesting! PR #s? (Hint hint hint :-) )
Thank you! > Okay, so I opened https://gcc.gnu.org/PR125518 for that. > > The similar https://gcc.gnu.org/PR121426 has been resolved by pulling > the sledge hammer as Stefan calls it: combine.cc rejects all insn > combinations that involve hard-reg constraints. I don't agree with that patch at all, and I am the sole combine maintainer, so I wonder what happened here. The problem description itself already is nonsensical: "Fixed by pulling the sledge hammer and rejecting any resulting insn which makes use of hard register constraints." No instruction pattern ever "makes use of constraints", that is confusing some basic concepts :-( > I understand that fixing RA stuff is hard and only a hand-full of > guys can do it, yet it would be great if insns with hard-reg > constraints could be insn-combined. And they can be, there is absolutely no reason to make such an artificial limitation. > What's confusing is that IRA doesn't seem to care at all about the > upcoming conflict, and leaves the mess to LRA which must solve > it as an afterthought. And test cases like from PR125518 might > be much easier to track and resolve than bug reports with > real-world test cases with 1000 lines of code or more... The comflict partially is hand-written by the user unfortunately. It isn't very surprising (or even unwanted!) that IRA gives up in some of those cases. But reload (LRA now) should be able to handle this always. > What my be related are similar "conflicts" with local register vars. > Suppose: > > register int arg1 __asm("r24") = 0; > register int arg2 __asm("r22") = a / b; > > where the division clobbers R24 or sets it as a side effect. > The docs say that this code is not supported, though it *could* > be supported if each register var was assigned its own pseudo, > and RA would handle it properly. That is how things were done years ago. Note I don't say "how things worked back then": it didn't work. > The pseudos would be moved to > the respective hard reg right before the inline asm that uses them. Local register vars are meaningless except when used in inline asm, since quite a few years already (and that is because they didn't actually work in other contexts since way longer already, and there was absolutely no way to make them work, only on happy cases). > Would be nice if the users could write their code without knowing > whether an initialization / assignment triggers some libcall. You cannot know in general, but usually you trivially do know. Segher
