On 5/26/2026 8:22 AM, Robin Dapp wrote: > From: Robin Dapp <[email protected]> > > This patch adds dependent-filter support to lra. As with register > filters, this is the part that ensures correctness, while the later > ira patch improves register allocation. > > As dependent filters can be expensive, the patch adds a hash-table > cache that is integrated into lra_get_dependent_filter. > > In order to keep track of dependent filters during pseudo phases, the > patch adds a vector of them to lra_reg. It is filled after reloading > and queried in find_hard_regno_for_1 so we can fold it into > conflict_set. > > gcc/ChangeLog: > > * lra-assigns.cc (find_hard_regno_for_1): Query dependent > filter of current pseudo. > * lra-constraints.cc (struct dependent_filter_cache_hasher): New > hasher. > (lra_init_dependent_filter_cache): New function. > (lra_finish_dependent_filter_cache): Ditto. > (lra_reset_dependent_filters): Ditto. > (lra_get_dependent_filter): New function to query (and add) > a dependent filter from/to the cache. > (lra_add_dependent_filter): New function to add a dependent > filter to an lra_reg. > (get_dependent_filter): New function to get a dependent filter > from a constraint. > (process_dependent_filters): New function to get all dependent > filters from the current insn's constraints. > (process_alt_operands): Initialize dependent-filter regset. > (curr_insn_transform): Fill lra_reg dependent filters. > * lra-int.h (struct dependent_filter): Declare. > (struct dependent_filter_entry): Ditto. > (lra_init_dependent_filter_cache): Ditto. > (lra_finish_dependent_filter_cache): Ditto. > * lra.cc (initialize_lra_reg_info_element): New function. > (finish_reg_info): Release dependent-filter vector. > (lra_init_once): Init hash table. > (lra_finish_once): Clear hash table. > * lra.h (lra_reset_dependent_filters): Declare. So at a high level, we have the cache, that's per function, right? I just want to make sure we don't have to deal with whether or not the cache needs to be invalidated because a function has an optimize attribute that perhaps changes vector configuration info. While I don't immediately see a problem with that, it's a slight worry.
By attaching the filter the pseudo we effectively are incorporating the filter aspect on a global basis for that pseudo. Do we have concerns that the filters accumulated through the various use points could ultimately result in a pseudo that we can't allocate to a hard register? I guess that's always been a concern and we're just exposing it in a different way with your patches in this space. Do you need to manage free-ing dependent_filter_entries? Or is that hidden in the bowels of the hash table template code? I realize Vlad has already looked at the IRA/LRA patches. So any comments he had take precedence over mine. > + > + /* If this filter already exists, do nothing. */ > + FOR_EACH_VEC_ELT (filters, i, filter) > + if (filter->id == id > + && filter->partner_regno == (unsigned int) partner_regno > + && filter->mode == mode && filter->partner_mode == partner_mode > + && filter->is_ref == is_ref) > + return; Hoping we never get too many of these since this is just a linear search down the list. Generally looks sensible. jeff
