I detected in the actual version 4854 that it produces unneeded slocs if the result is a bit and the literals after ? and : are bits too.
I attached a smal source file where it can be reproduced
Source for the behavior descripted above
Logged In: YES
This should be a more generic request: For any assignment from a tri-op a temporary is used which most of the time can be avoided. The temporary can be in registers or an sloc.
Only one special case where the result is a bit and the two operands are literals is currently optimized.
void test(unsigned char x)
b = (x<1) ? 1 : 0; // only this goes without iTemp
b = (x<2) ? (bit)1 : (bit)0; // uses a bit sloc
c = (x<3) ? 1 : 0; // uses a register
c = (x<4) ? (char)1 : (char)0; // uses a register
i = (x<5) ? 1 : 0; // uses a register
i = (x<6) ? (long)1 : (long)0; // uses several registers
I was looking into this further, but I am stuck now.
The casts on the literals are not yet replaced by a new literal of the casted type because the ':' part is not decorated yet. And this is done on purpose by a change to SDCCast.c made by Sandeep in revision 1627. His comment, which I do not understand, is:
/* delay right side for '?' operator since conditional macro expansions might rely on this */
Can anyone shed some light on this?
I ran the regression tests with the exception made by Sandeep disabled and found something. Have a look at this:
char *str = 1 ? NULL : "never";
When the right side is decorated before the condition is evaluated the constant string "never" is put in code anyway.
The same is true btw. for the following code.
char *str = "unused";
There is no code generated for the assignment and no space allocated for str, but the (unused) constant string IS put in the CONST segment.
And that is how one feature request becomes a totally different one.
A carefully chosen position of the optimizing code circumvents the problems I mentioned.
So this request is now implemented in SDCC 2.7.4 #4930.