> 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.
Yeah, we reset in ira per function. But I just realized that I should rather put it in lra's init. Doing that in v2. > 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. Definitely a concern but my hope is that if we hit that case it's rather a real bug in defining constraints, rather than due to the way we allocate. Just a hope, though, and no definite proof. > Do you need to manage free-ing dependent_filter_entries? Or is that hidden > in the bowels of the hash table template code? Yep, I outsourced this to : free_ptr_hash <dependent_filter_entry> -- Regards Robin
