On Thu, Jun 18, 2026 at 03:56:22PM +0200, Stefan Schulze Frielinghaus wrote: > On Tue, May 26, 2026 at 04:22:42PM +0200, Robin Dapp wrote: > > From: Robin Dapp <[email protected]> > > > > Building upon Richard's register filters, this patch series introduces > > filters > > that can base their filtering decision on a second operand: The > > constrained > > operand (the "dependent" operand), and the "referenced" operand. > > This allows e.g. to constrain the dependent operand relative to the mode of > > an > > output operand. For RISC-V, a typical example is when a source of a > > widening > > vector instruction must either not overlap the destination at all or only a > > specific subreg of the destination. > > > > A major difference to register filters is that dependent filters are > > dynamic > > and can therefore be significantly heavier in compile-time. Also, by their > > nature, they are order-dependent, influencing greedy coloring heuristics. > > > > I haven't observed a compile-time hit across SPEC but so far only tested > > with > > a single dependent filter. I wouldn't expect too many dynamic filters > > active > > at the same time and still added a simple caching scheme. > > > > The series is organized similarly to Richard's. First, the gen plumbing, > > then > > recog. The lra change should be sufficient for correctness and the ira > > patch > > improves register allocation. The RA changes have been slightly > > "whack-a-mole"y. I just added handling until I got the expected results. > > Further input and ideas towards a more comprehensive solution appreciated. > > To get this right out of the way, I like the generality of this > approach. I'm not entirely sure whether I grasped the order of > execution right. So let me rephrase: > > During IRA colouring, a register is considered for allocation only if it > is contained in the intersection of all dependent filters (side remark I > haven't fully wrapped my head around what this means in case of multiple > alternatives or alternatives consisting of multiple constraints; we > might favor dependent filtered constraints here). If aclass and dep > filters don't intersect, no register is chosen and consequently > scheduled for spilling (this is where I started to wonder about multiple > alternatives and alternatives containing multiple constraints and how > those influence each other). This is the same for the corner case where > we end up with the empty intersection of all dependent filters. > > During LRA constraint, a filter is installed only if the referenced > operand is a register which is either a hard register or a pseudo which > is already assigned a hard register. Otherwise we wait until the > referenced operand gets a hard register assigned. So if we ever ran > into a transitive case where (A,B) are constrained via dependent filters > and (B,C), too, then allocation for C would ripple backwards into B > which then would influence the allocation of A, though, probably not the > intended use case ... just trying to understand how it behaves. > > Maybe in get_dependent_filter() one also wants to deal with > subreg(reg) for pseudos which have been allocated a hard register? > > I like the utilization of the exclude_start_hard_regs thingy; rings a > bell ;-) What also comes to my mind is that for hard register > constraints I have a wip patch for IRA costing (in particular aclass > selection). Maybe that could be something (for a future patch) here, > too? > > In general looks sensible to me.
Forgot to add: I think this could suffer from a similar problem hard register constraints or in general single register constraints suffer, too. Assume that the dependent register is constrained to a hard register which is live at that insn. I would expect to see an ICE there because reloads would be required here, however, reloads are only introduced for pseudos but not for hard registers. For hard register constraints I'm still experimenting with some solutions, though, haven't found a silver bullet so far. Still I think this is solvable. The question is rather how does a solution look like with an adequate amount of reloads/spills. Cheers, Stefan
