On Thu, Nov 17, 2016 at 04:50:46PM +0000, Kyrill Tkachov wrote: > >>Is loading/storing a pair as cheap as loading/storing a single register? > >>In that case you could shrink-wrap per pair of registers instead. > > > >I suppose it can vary by microarchitecture. For the purposes of codegen > >I'd say > >it's more expensive than load/storing a single register (as there's more > >memory bandwidth required after all) > >but cheaper than two separate loads stores (alignment quirks > >notwithstanding). > >Interesting idea. That could help with code size too. I'll try it out. > > I'm encountering some difficulties implementing this idea. > I want to still keep the per-register structures across the hooks but > basically restrict the number > of components in a basic block to an even number of FPRs and GPRs. I tried > doing this in COMPONENTS_FOR_BB
So your COMPONENTS_FOR_BB returns both components in a pair whenever one of those is needed? That should work afaics. > but apparently this ended up not saving/restoring some of the registers at > all because the components that were > "filtered out" that way still made their way to the bitmap passed into > SET_HANDLED_COMPONENTS and so the normal > prologue/epilogue didn't end up saving and restoring them. I am not sure what this means? "filtered out"? Segher