When there is an integral constant like `3` in an expression, it has
type `int` according to the C spec, even though it can be represented
as an `unsigned char`. Change codegen (`hie_internal` and `typeadjust`)
to treat it as `unsigned char` instead of `int` so that faster,
unsigned operations can be used.
For the test case in #1298, reduces the cycles per iteration from
4311 to 1884. This is a great improvement, but still much worse than
the 1053 cycles/iter from `c4698df~`, so more work remains to be done.
Further partial fix for #1298 and #1308.
In g_typeadjust, before we apply the integral promotions, we check if
both types are unsigned char. If so, we promote to unsigned int, rather
than int, which would be chosen by the standard rules. This is only a
performance optimization and does not affect correctness, as the flags
returned by g_typeadjust are only used for code generation, and not to
determine types of other expressions containing this one. All unsigned
char bit-patterns are valid as both int and unsigned int and represent
the same value, so either signed or unsigned int operations can be used.
This special case part is not duplicated by ArithmeticConvert.
Partial fix for #1308.
This usually allows faster & smaller code.
Note that deferred operations must still be called at sequence points even if the whole expressions containing them had constant values.
Partial fix for ICE in #1211. This may fix enough to allow #1049 to be
fixed.
When merging labels, keep the first label with a ref that has no JumpTo;
this is a data segment label, used by computed gotos.
The real fix is to track and rewrite labels in data, but this is more
involved.
Fixes#1267
Avoid ICE, but treat plain int bit-fields declared via typedef as
signed rather than unsigned. It is more efficient to treat them
as unsigned, but this requires distinguishing int from signed int,
and this is curently not done.
Fix copy & paste bug with warning message.
struct X {
signed int a : 3;
};
struct X g = { 5 };
Before:
s.c(4): Warning: Implicit truncation from 'int' to 'int : 3' in bit-field
initializer changes value from 5 to 5
After:
s.c(4): Warning: Implicit truncation from 'int' to 'int : 3' in bit-field
initializer changes value from 5 to -3
Fixes#1268
Made cc65 replace a bad bit-field type with a good one, and always parse the field width.
Shortenned a parameter name to a spelling that's consistent with other function headers.
Some existing optimizations are impacted and need fixes in order to work correctly again.
Fixed and improved OptPrecalc. Now it respects the C/V/Z/N flags.
Fixed optimizations impacted by added support of tracking processor flags.
Added ZNRegs for tracking what register(s) Z/N flags currently reflect.
Added utility functions to check if the specified processor state is known to be a certain value.
