Re: init_reg_autoinc bug and how to describe regs that can't autoincdec

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Date: Wed, 21 Nov 2007 17:03:27 EST

> > So for the actual bug I see, I need to find out why reload
> > doesn't do that, if I understand you correctly.
> 
> Right, that's my claim.

That is understood.

> > But still, why is forbidden_inc_dec_class all 0 here,
> > particularly for classes containing this register?  Surely the
> > code should be changed to make it 1 for such classes, so there'd
> > be no invalid allocations for reload to fix up!
> 
> That's a matter of *preferencing* and indeed that should be done someplace.
> But you *have* to allow generating references for reload to fix up.

Sure.  If I wasn't clear in my previous message, I'd understood
the difference between the preferencing-bug and the reload-bug.

My claim is that the preferencing machinery is way wrong here,
and with no nonhackish way to state other than some obscure
special-case preference, because of a non-fatal bug.  (Which in
turn exposed the reload-related bug.)

I need to rephrase my question: how should this code change to
also work for (as in: guide register allocation away from) a
register class that can't be used for autoincdec but doesn't
need secondary reloads?

I mean, by naming, by the head comment and at a glance it seems
it's generally intended to guide register allocation regarding
autoincdec, but can currently only help in an obscure case which
you say probably even isn't useful anymore.  Why not improve it?

> In the case at hand, suppose you have a pseudo that's used 100 times
> in insns where a certain register class is acceptable for those the
> operand in which its used and one insns as an autoinc for which that
> class isn't valid.  Isn't it better to allow those other 100 uses to
> proceed efficiently and do copy in and copy out around the autoinc than
> to not handle those other 100 insns efficiently?  This is the whole point
> of the register choice and preferencing mechanisms.

Now that you've said all that...that's not what happens.
(It's rarely what you think would be a nice logical explanation. :)

>From reading the local-alloc dump, it's a register used over
several basic-blocks (of course, else it'd failed in local, not
global) but in every use except two, it's copied to itself or
used in a post_inc address.

...but (in absence of non-zero forbidden_inc_dec_class) the
actual wrongful allocation seems to be introduced by reload.
Oh my.  News at 11.

brgds, H-P