Reducing number of arrays used by reload

Michael Meissner meissner@cygnus.com
Fri Jan 22 11:44:00 GMT 1999


On Thu, Jan 07, 1999 at 01:08:44AM -0700, Jeffrey A Law wrote:
> 
>   In message < 13968.37864.679050.967966@ongaonga.elec.canterbury.ac.nz >you writ
> e:
>   > 
>   > 
>   > Here's the patch I mentioned the other day to collect the
>   > plethora of arrays used by reload into an array of structures.
>   > 
>   > Michael.
>   > 
>   > Mon Jan  4 22:44:26 1999  Michael Hayes  <m.hayes@elec.canterbury.ac.nz>
>   > 
>   > 	* reload.h (struct reload_info): New structure definition.
>   > 	* reload.c (reloads): New array.
>   > 	(reload_in, reload_out, reload_regclass, reload_inmode,
>   > 	reload_outmode, reload_reg_rtx, reload_optional, reload_nongroup,
>   > 	reload_inc, reload_in_reg, reload_out_reg, reload_nocombine,
>   > 	reload_opnum, reload_when_needed, reload_secondary_p,
>   > 	reload_secondary_in, reload_secondary_out, 
>   > 	reload_secondary_in_icode, reload_secondary_out_icode,
>   > 	reload_mode, reload_nregs, reload_inherited, reload_inheritance_insn,
>   > 	reload_override_in, reload_spill_index): Replaced arrays by 
>   > 	reloads array of struct reload_info.
>   > 	* reload1.c: Likewise.

I would make a suggestion that you put the array accesses wrapped with a macro
(see the regs.h for how I handled it for the global register info).  It also
allows us to put in subscript checking code in with --enable-checking to catch
errors where we go outside the bounds of the array.  If you use the varray
support as well, it gives you the range checking automatically.  Another
benifit of the accessor macros, is you can change the implementation -- for
example, at some point, I want to look at adding the pass specific data based
on register # into the reg_info structure as a union -- that way you colesce
multiple allocations into one.

I didn't see the original patch, but if you are using alloca, it might be
better to use explicit xmallocs and frees (or obstack usage).  Long term, all
of the large alloca tables need to be changed into xmallocs, etc.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)



More information about the Gcc-patches mailing list