[0/9] Make HARD_REG_SETs easier to use

[Richard Sandiford <richard.sandiford@arm.com>]

I have a series of patches that allows several ABIs to be used
interoperably within the same translation unit.  Part of that involves
removing our reliance on global register sets that describe "the ABI".

One of the difficulties is that we have several global sets that contain
related information.  E.g.:

   call_used_reg_set == regs_invalidated_by_call | fixed_reg_set

call_fixed_reg_set is derived from call_used_reg_set.
no_caller_save_reg_set is in turn derived from call_fixed_reg_set.

I don't think there's a strong efficiency reason for having a global
cache of things like call_used_reg_set above.  On most targets the
"|" operation is two (parallel) 64-bit logical ORs of nearby data and
so should be very cheap to compute.  I think the sets are more there
for convenience.  And I think the main reason they're convenient is
that HARD_REG_SET is so unwieldly to use.  E.g. if you want to do:

   a &= b | c;

you have to write:

   HARD_REG_SET tmp;
   COPY_HARD_REG_SET (tmp, b);
   IOR_HARD_REG_SET (tmp, c);
   AND_HARD_REG_SET (a, tmp);

Again, each of these operations is individually very cheap on most
targets (a couple of moves or logic ops each).  But because it takes
so much code to write, there's a strong temptation to cache "b | c"
if it's used often.

This series therefore provides the following operators for HARD_REG_SET
and converts existing code to use them:

  = ~ & &= | |= == !=

The reason for picking (only) these is that they work on plain integer
bitmasks too, and so we can continue to treat HARD_REG_SET as a plain
integer when FIRST_PSEUDO_REGISTER is small enough.  As noted at the
end of the covering note for the first patch, that might be overly
conservative, since the sets aren't passed by value all that often
and so the performance gain is probably very slight in practice.
I nevertheless stopped here because the series seems like a strict
improvement compared to the status quo and is all that I need for the
motivating follow-on series.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  Also tested by
compiling one target for each CPU directory and making sure that
there were no changes in assembly code for gcc.c-torture, gcc.dg
and g++.dg.  (This was before the eBPF port went in, but that's
conveniently free of HARD_REG_SETs.)

Richard