[RFC] avoiding too narrow register classes in reload

[Alexandre Oliva]

On Dec 14, 2004, Richard Henderson <rth@redhat.com> wrote:

> On Mon, Dec 13, 2004 at 07:20:21PM -0200, Alexandre Oliva wrote:
>> Does this look like a reasonable approach?

> Yes.

>> Should other locations that compare
>> reg_class_size with 1 be adjusted similarly?

> Probably would be good.

Here's the patch I've bootstrapped and tested on x86_64-linux-gnu.
There's one use of reg_class_size that I wasn't sure whether to
replace with the new macro, in combine_reloads():

							     rld[output_reload].out))))
	&& ! reload_inner_reg_of_subreg (rld[i].in, rld[i].inmode,
					 rld[i].when_needed != RELOAD_FOR_INPUT)
	&& (reg_class_size[(int) rld[i].class] || SMALL_REGISTER_CLASSES)
	/* We will allow making things slightly worse by combining an
	   input and an output, but no worse than that.  */
	&& (rld[i].when_needed == RELOAD_FOR_INPUT

The logic was different from all other cases, that tested for
reg_class_size[...] == 1 || SMALL_REGISTER_CLASSES, and I couldn't
tell whether it was on purpose or a typo.  Can anyone?

I realize the patch introduces some possibly-significant semantic
changes, in that NO_REGS is now regarded as a SMALL_REGISTER_CLASS_P
and so it passes a number of cases where we tested for
reg_class_size[...] == 1 || SMALL_REGISTER_CLASSES.  Since
SMALL_REGISTER_CLASSES would pass, I figured this couldn't be a
problem.  The last hunk, where || SMALL_REGISTER_CLASSES wasn't
present, uses the new predicate but also ensures that reg_class_size
is non-zero (it broke otherwise).  Does it make sense to narrow the
predicate to hold only for non-empty classes, and adjust the
one-before-last hunk, that uses the negated predicate in a way that
requires it to hold for empty classes?

Ok to install this for now?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reload-small-regclass-likely-spilled.patch
Type: text/x-patch
Size: 4133 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20041214/a2d77519/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}