The issue "[sdcc-devel] pic14 code size increase from sdcc 3.5.0 to 3.5.5-trunk"
https://sourceforge.net/p/sdcc/mailman/message/34689491/
is not specific to the pic14 port.
The attached source reproduces the unexpected (at least for me) use of 16 bit instead of 8 bit operations for e.g. mcs51 with sdcc 3.5.5 #9437
Philipp changed char literal from char type to int for supporting _Generic in C11.
This feels ridiculous. SDCC is especially for targettng 8 bit processors. This should be solved instead waved away.
Need further optimization.
Quick comparison using current (#9441) sdcc.
character literals as int:
character literals as char:
Philipp
Ticket moved from /p/sdcc/bugs/2447/
Can't be converted:
Moved to feature requests, since I consider this to be a feature request for optimization: Where a character literal is compared to a char, SDCC should optimize the comparison into an 8-bit one.
For some reason, SDCC currently is sometimes able to optimize comparisons of char to integer constant expressions other than character literals. We would want the optimization to work for character literals, too.
Both of the following should result in an 8-bit comparison:
Similar for the switch case labels.
Philipp
Actually, it seems, in SDCC, integer constants without suffix in the range -128 to -1 have type signed char, and those in 0 to 255 have unsigned char.
Looking at constVal() integer constants seem to be quite a mess wrt. their type. IMO, integer constants should have the type the standard says. And an optimization should later deal with making the operations cheaper.
Philipp
Ticket moved from /p/schlange/feature-requests/3/
I accidentially moved the ticket to the wrong project when moving it to feature requests.
Philipp
In revision [r9442], I introduced an optimization for comparions of cheap variables to expensive constants. This makes comparisons 8-bit again, even with int character literals. And it optimizes some further cases. e.g. for an unsigned char d,
was a 32-bit comparison before, but now its an 8-bit comparison. The optimization makes code size go down on the regression tests, but not as much as character literals being char. This is not surprising, since I only implemented the optimization for explicit comparisons, but didn't look at switch or other constructs yet.
Philipp
Last edit: Maarten Brock 2016-01-04
Actually the switch from the example is optimized, too, since geniCodeLogic() is involved, and I implemented the optimization there. I'll have to investigate which other places will need optimizations to completly eliminate the code size increase from changing the type of character literals to int.
Philipp
I just forgot to recompile the library before comparing the code size on the regression test. I just recompiled it now, and it turns out that code size with the optimization and character literalsof type int is already lower compared to without the optimization and type char. So I'm closing this issue now.
Philipp
P.S.: I compared code sizes using stm8 and mcs51-stack-auto.
If I read you right, you only optimized comparisons. I would expect the same issue with arithmetic. E.g.
unsigned char x, y;
x = y + 10;
My suspicion is that the constant 10 is now a (signed) int, y gets cast to int too and the addition is done in 16 bit before the result is cast back to an unsigned char and assigned to x.
But worse, [r9442] fails to build the hc08 library:
If you always build with "make > /dev/null" this should have been easy to catch.
I havent changed 10 from char to int yet. But assume x = y + 'c';
Old behaviour: 'c' is char, integer promotion casts y and 'c' to int. Optimiziation makes the + 8 bits since x is unsigned char.
New behaviour: 'c' is int, integer promotion casts y to int. Optimiziation makes the + 8 bits since x is unsigned char.
Same code results.
Philipp
In revision #9443 I disabled the optimization for hc08 and s08. See also bug #2450.
Philipp
Enabled for hc08 and s08 in rev #9681.
Philipp
Even though in general, character literals of type int + the optimization for compares tends to give much smaller code than character literals of type char, there are exceptions:
I'll look into these when I find time, maybe tomorrow.
Philipp