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

Reply via email to