Menu
▾
▴
#222 Constant subexpression not evaluted at compile time
Constant pointer subexression within conditional evaluted at runtime only instead of at compile time.
Constant expressions 'Values[0].Name' and 'Values[1].Name' evaluted at compile time when standing alone in an assignment (correct, optimal behaviour), but second subexpression is evaluated only at runtime when used within conditional assignment 'p=i ? Values[0].Name : Values[1].Name;' (suboptimal behaviour). This results in bigger code and longer runtime.
See attached source file for more details.
Command to compile:
C:\>sdcc BugReport8.c
C:\>sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.4 #4972 (Nov 23 2007) (MINGW32)
Logged In: YES
user_id=888171
Originator: NO
The following fragment in packRegisters() in src/mcs51/ralloc.c is responsible for this. In particular the result operand for this piece of code is defined in two places, namely the true and the false clause.
At this time however the iCode-tree no longer knows about the ternary operator.
/* if this is an itemp & result of an address of a true sym
then mark this as rematerialisable */
if (ic->op == ADDRESS_OF &&
IS_ITEMP (IC_RESULT (ic)) &&
IS_TRUE_SYMOP (IC_LEFT (ic)) &&
bitVectnBitsOn (OP_DEFS (IC_RESULT (ic))) == 1 &&
!OP_SYMBOL (IC_LEFT (ic))->onStack)
{
OP_SYMBOL (IC_RESULT (ic))->remat = 1;
OP_SYMBOL (IC_RESULT (ic))->rematiCode = ic;
OP_SYMBOL (IC_RESULT (ic))->usl.spillLoc = NULL;
}
I do not consider this a bug but a request for better optimization. For now I will not pursue this further.
Maarten