public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [0/9] Make HARD_REG_SETs easier to use
@ 2019-09-09 15:52 Richard Sandiford
  2019-09-09 15:54 ` [1/9] Simplify the implementation of HARD_REG_SET Richard Sandiford
                   ` (8 more replies)
  0 siblings, 9 replies; 21+ messages in thread
From: Richard Sandiford @ 2019-09-09 15:52 UTC (permalink / raw)
  To: gcc-patches

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2019-09-10  9:16 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-09 15:52 [0/9] Make HARD_REG_SETs easier to use Richard Sandiford
2019-09-09 15:54 ` [1/9] Simplify the implementation of HARD_REG_SET Richard Sandiford
2019-09-09 17:35   ` Jeff Law
2019-09-09 18:05     ` Richard Sandiford
2019-09-10  9:16       ` Oleg Endo
2019-09-09 15:58 ` [2/9] Remove COPY_HARD_REG_SET Richard Sandiford
2019-09-09 17:36   ` Jeff Law
2019-09-09 15:59 ` [3/9] Remove COMPL_HARD_REG_SET Richard Sandiford
2019-09-09 17:37   ` Jeff Law
2019-09-09 16:00 ` [4/9] Remove AND_HARD_REG_SET Richard Sandiford
2019-09-09 17:38   ` Jeff Law
2019-09-09 16:00 ` [5/9] Remove IOR_HARD_REG_SET Richard Sandiford
2019-09-09 17:39   ` Jeff Law
2019-09-09 16:01 ` [7/9] Remove IOR_COMPL_HARD_REG_SET Richard Sandiford
2019-09-09 17:41   ` Jeff Law
2019-09-09 16:01 ` [6/9] Remove AND_COMPL_HARD_REG_SET Richard Sandiford
2019-09-09 17:40   ` Jeff Law
2019-09-09 16:02 ` [8/9] Remove hard_reg_set_equal_p Richard Sandiford
2019-09-09 17:41   ` Jeff Law
2019-09-09 16:03 ` [9/9] Tweak interface to ira-build.c:ior_hard_reg_conflicts Richard Sandiford
2019-09-09 17:42   ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).