> 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.
Yeah good point. I haven't really thought about multiple dependent-filter constraints in a single alternative. My idea was that such cases should be handled in a single dependent filter and the target function should have both cases. > 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. (or worse: A,B,C,A :/) I was trying to convince myself that those are user errors, though :) Yes, that was the general idea. Even though dependencies necessarily induce an order, we don't follow this order during allocation and making a wrong choice early on cannot be corrected. I haven't observed such cases in my limited testing but the more dependent filters we get, the higher the chances, I guess. I think the worst case is an additional unnecessary reload. We'd probably need a specific heuristic for dependent filters if we wanted to avoid this altogether? Doesn't sound great... > 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? Yes, I think that might help here as well. Thanks for going through the patches! -- Regards Robin
