Am 13.04.2012 10:06, schrieb Erik Petrich:
> On Wed, 11 Apr 2012, Philipp Klaus Krause wrote:
>> Some issues that might be easy to solve for the hc08 people, but
>> currently don't look obvious to me:
>> * Regression test bug1908493.c fails to compile
> Currently (revision #7578) all of the regression tests will at least
> compile (but not necessarily pass their tests).
>> * When enabling '!' or IFX or CAST in instruction_cost(),
>> hc08/ralloc2.cc there is a SIGSEGV in asmopToBool() when compiling
>> regression tests
> Currently, this is also fixed.
>> * When enabling '+' in instruction_cost(), hc08/ralloc2.cc there is a
>> problem with genPointerGetSetOfs() when compiling regression tests.
> Not fixed, but a temporary fix would be for genPointerGetSetOfs to
> immediately return 0 (false). It's looking for the case where a constant
> is added to a variable and the result used as a pointer get or set. In
> this case, the addition can be performed as part of the indexed addressing
> mode rather than a separate instruction.
> Could the register allocator be changed to only allow the use of the H
> register as part of the HX pair? H is virtually unuseable as an 8-bit
> register, so assigning an operand to it is more expensive than if the
> operand spilled to memory.
Are you sure it is always like that? There is crlh, which is a one-byte
instruction to clear h, which can cheaply store 0 into h and there can
be an 8-bit left shift, which could be cheap when the left operand is in
h and the result in hx. So it seems to me, that for some cases using h
would be a better choice than spilling.
When the cost function is completly working (i.e. no instructions that
might generate different code depending on register assignments are
disabled in instruction_cost() and the regalloc_dry_run_cost gives the
correct code size everywhere) the allocator becomes optimal: It will
find a register assignment that results in minimal code size. Thus, h
would then be used only in the rare cases where it gives an advantage.
The more choices there are for the allocator, the better the results get.
In particular, the code generator should be able to cope with registers
that are alive. Currently code generation uses isFree, which currently
is true if no operand of the current instruction is in the register. I
intend to also add isDead, which would be true if the value in the
register does not need to survive the instruction.
P.S: Since some regression failures were related to 8-bit operands in h,
I disabled it for now, but I think it should be reenabled in the long term.