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.
Test expressions like `unsigned char x = ...; ... = x / 2;`
These use `int` constants with values representable by
`unsigned int` / `unsigned char`, so using unsigned codegen should
be possible.
Additional tests for #1308. These are things we want to generate better
code for, so add tests that the behavior doesn't change.
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.
Both signed and unsigned chars are promoted to int by C's evaluation
rules. It is more efficient to use unsigned operations when possible,
however. These tests will help test the correctness of optimizations
doing that. See #1308.
* Docs say that CLK_TCK is an obsolete alias of CLOCKS_PER_SEC so there's no point in individual definitions.
* All targets determining the clock rate at runtime can use a common handling.
Requiring the HGR segment makes the configs a little less flexible, but for the intended use case the HGR segment actually is necessary. And as we learned now, making the HGR segment obligatory helps users to not shoot themselves in the foot.
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.
