This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Sharing hard registers
- From: law at redhat dot com
- To: "David S. Miller" <davem at redhat dot com>
- Cc: jh at suse dot cz, apl at alum dot mit dot edu, echristo at redhat dot com, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Jun 2002 04:51:37 -0600
- Subject: Re: Sharing hard registers
- Reply-to: law at redhat dot com
In message <20020614.032125.112382908.davem@redhat.com>, "David S. Miller" writ
es:
> From: law@redhat.com
> Date: Fri, 14 Jun 2002 04:23:59 -0600
>
> The latter is the reason why I think we can make shared hard regs
> work -- the compiler already has to deal with shared hard regs
> after reload. The only code that should cause us problems is stuff
> generated in the prologue/epilogue expanders by the backend.
>
> Ok. The one issue is the fact that we can refer to a hard reg in many
> different modes (whereas pseudos have a single mode in which they are
> referred).
Correct.
> So if we allow hard reg sharing, it would be on a per-mode basis.
Correct. The generalized sharing code in gen_rtx_REG only sets up shared
hard regs for regno_raw_mode[regno].
However it's possible that a specific optimization pass or the backend could
set up other shared registers with different modes. For example, a backend
might arrange to share argument registers with a mode other than
regno_raw_mode.
I pondered doing this briefly, but when I looked at the profiling data it
just didn't seem worth the effort.
> To implement this we could have a table for each hard reg, similar to
> some of the stuff you implemented already Jeff. However, each entry
> would be a list of REG objects. When we try to gen a hard REG we
> check the list, if we can't find one for the mode being requested we
> allocate one and add it to the list.
>From the profiling data it doesn't appear to be worth it -- once you're sharing
regno_raw_mode hard regs you've got 99% of the benefit of sharing hard regs.
jeff