Jeff Law <l...@redhat.com> writes: > On 9/9/19 9:53 AM, Richard Sandiford wrote: >> We have two styles of HARD_REG_SET: a single integer based on >> HOST_WIDEST_FAST_INT (used when FIRST_PSEUDO_REGISTER is small enough) >> or an array of integers. One of the nice properties of this arrangement >> is that: >> >> void foo (const HARD_REG_SET); >> >> is passed by value as an integer when the set is small enough and >> by reference otherwise. > True, but I suspect that few, if any, important targets are able to use > the simple integer version. > > >> >> However, one of the disadvantages of using an array is that simple >> assignment doesn't work. We need to use COPY_HARD_REG_SET instead. > RIght. Clear historical wart. > >> >> This patch uses a structure wrapper around the array, and preserves >> the above "nice property" using a new const_hard_reg_set typedef. >> The patch also removes the manual unrolling for small array sizes; >> I think these days we can rely on the compiler to do that for us. > Certainly makes sense to me. Most of this was designed in the "early > days" when most targets had small register files. > >> >> This meant fixing two port-specific quirks: >> >> - epiphany passed NULL as a HARD_REG_SET whose value doesn't matter. >> The patch passes the NO_REGS set instead. >> >> - ia64 reused TEST_HARD_REG_BIT and SET_HARD_REG_BIT for arrays that >> are bigger than HARD_REG_SET. The patch just open-codes them. >> >> The patch is probably being too conservative. Very few places actually >> take advantage of the "nice property" above, and we could have a >> cleaner interface if we used a structure wrapper for all cases. > I wouldn't object to dropping the "nice property". I doubt it matters > anymore and if the result is cleaner and easier to work with, then it's > a net win.
Yeah. I might come back to this later and look at a fuller transition to C++ (or at least to try to get rid of CLEAR_HARD_REG_SET). Thanks, Richard