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. Cheers, Stefan
