Hi,
the use of inline assembly may lead to the optimizer being extra /
overly careful. I'm not sure if the peephole optimizer looks into the
resulting inline assembly or if it just sees a black box labeled
"inline assembly inside" and assumes the worst: 'a' is read in there.
Will it be extra careful? I'm not so sure. The SDCC manual states that
inline assembly code is passed through the peephole optimiser, so that
implies that it must consider the contents of such blocks when applying
rules. Effectively, I am guessing that the peephole optimiser does not
in fact know whether any particular line of assembly has been generated
by the compiler or included as-is from inline assembly.
Typically, only explicit or implicit writes to the register on all
possible later code path convince the optimizer that the value /
register is not used.
I think you are right. If I am interpreting the code in stm8/peep.c
correctly, what appears to happen is that notUsed() - via doTermScan()
and scan4op() - will return true if a write to the register is found
before any reads.
That makes sense, as it would be pretty stupid to say a register is "in
use" if it is read at *any* point in the function, regardless of whether
it has been assigned a new value in the meantime.
I still would like to know whether a "push a" counts as a read from that
register. If it does, should it? That instruction is basically saying
"save the value of A because it's going to be overwritten imminently".
I can probably solve the particular instance of this non-optimisation by
removing the "push a" and "pop a" pro/epilogue from my inline assembly,
as the following C code does not rely on A being maintained. But I am
hesitant to do so, concerned that I may inadvertently introduce a bug in
the future by changing the surrounding C code to something that does -
who knows what the compiler may do?
Regards,
Basil
P.S. By the way, I found my answer to the "%2" question: the last param
to immdInRange() is indeed a result output parameter. That would also
explain why the literal address gets converted from hex to decimal (e.g.
0x505b => 20571).
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
