RE: [sdcc-devel] Commit: disable packregsForOneuse for ds390 port

[Sandeep D. <sa...@dd...>]

I would agree OneUse stuff uses a lot of heuristics to determine
if DPTR can be used or not.. and it is difficult to predict what the
register allocator will spill. In any case Kevin I would suggest that
instead of taking it out totally.. make the heuristics more
constrained.. for example check only the previous or next iCode
so at least you will get some speed up for example

a(b());
The return from b will not be put into registers and moved to
DPTR immediately but will stay in dptr. So....no easy answers
just see the output of the compiler and put in special case checks...

Sorry......
Sandeep

-----Original Message-----
From: sdc...@li...
[mailto:sdc...@li...]On Behalf Of Kevin Vigor
Sent: Wednesday, October 18, 2000 12:14 PM
To: sdc...@li...
Subject: [sdcc-devel] Commit: disable packregsForOneuse for ds390 port


I have (reluctantly) disabled the packRegsForOneuse optimization in
ds390/ralloc.c.

The problem is that this routine allocates DPTR as the registers for
a symbol in certain conditions, after making sure that DPTR isn't
already in use.

The problem is that this is done before other register allocations,
so no spills have happened yet. If a symbol is spilled, it will
require the use of DPTR to access it, since spills take place to
XDATA space for the 390 port.

So packRegsForOneuse can choose to assign DPTR because it is not in
use, but then a later spill makes it so that DPTR actually is in use.
This is bad, and resulted in seriously broken generated code.

I have tried pretty hard to figure out a good way to handle this, but
I haven't got a general solution yet. So I have just turned off the
optimization.

In case anybody wants to have a crack at a proper fix, a small sample
which demonstrates the problem is attached: compile with sdcc -mds390
--model-flat24 --stack-10bit -c test5.c.

        Peace,
                Kevin