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: stormy16: limit SI reload regs


> This was in response to a different change to the xstormy16 backend,
> not to a change in reload.

Ok, I'm confused.  The original problem is that reload is choosing a
register in class EIGHT_REGS that causes gcc to later complain that
the register [pair] doesn't meet the constraints.

My initial patch was to tell reload to use a different class, so that
it wouldn't pick the wrong register.  You claimed that it wouldn't fix
all the problems, because the wrong register might get chosen
elsewhere and bypass reload.

So I suggested a patch which should make sure the wrong register was
never chosen, even outside of reload.

So if I do fix reload to honor HARD_REGNO_NREGS when considering
candidates, what assurances do I have that nowhere else in gcc will
choose that register?  And if it's safe to just fix reload, then
what's wrong with just telling reload to use a different class?  And
how do we know that other ports won't be harmed by changing the rules
about the preferred reload class?  Maybe they've already fixed their
ports to use smaller classes.


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