This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sharing hard registers


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]