After many hours of testing I think I have generated an extensive and useful set of tests for these operations.
I attach the 7 different test files.
Many of them are quite massive in terms of cases.
Please check if all files are ok for you, If they are, I can upload my patches for the rules for STM8.
[patches:#362]
All the rules but 2 are used by the whole regression tests (and those can be commented or eliminated).
My tests cover 91% of the rules, the rest is covered by existing tests.
If we validate these tests, I hope it will be easier to validate the rules, even though I understand the rules quantity is quite massive.
Some test cases require the use of absolute addresses, I know the addressing space of STM8 and what ranges are available, for the other platforms, these tests are run as what I call DUMMY tests (a test with no real code for testing).
This is handled like this:
and later:
Finally if DUMMY_CASE is defined, the whole test is processed as empty, just an empty test, no assertions.
Whoever is more familiar with the other platforms should fill one or two addresses for the other platfoms.
Last edit: Visenri 2021-04-06
One of the tests in stack-restore needs >256 bytes of stack, so it can't be used in all platforms.
I just added the same check I've seen used in other similar tests:
Excluding those platforms from the test, but I have not done any test beyond STM8 platform.
Thanks. I'll have a closer look later this week; I guess we'll adopt the tests with minor modifications (choosing suitable absolute addresses for some of the z80-related ports) then.
bitfields-bits, bitfields-checks, bitfields-nibbles have a lot of tests. Over 3000 for each of them. This seems excessive, especially considering that typically, there are some weaker machines in the compile farm and that SDC developers should run the tests before comitting. Would it be possible to reduce the number without compromising peephole rule coverage? bitfields-dead-loop also has a lot, but not as many as the other two.
For addresses that should work for other targets, see the test absolute.c (it is probably best to use addresses in RAM for tests, not in I/O space).
In [r12207], I added the three tests that do not use absolute addresses.
I know, there are a lot of tests, I suffered it myself.
I just wanted to cover all possible cases.
This allowed me to pick a typo in one rule that was only a problem for some cases.
The rules themselves will be covered using far less tests, but not all combinations that lead to a similar final result will be covered.
For example, many rules apply several times for rotations and swaps until we end up in a "bset", "bres", "bcpl", but the combinations are different for each bit.
The same thing happens with nibbles tests, generating a single "or", "xor" or "and".
And these combinations are slightly different for each bit in the variable, and also sometimes the combinations change with the variable location (stack, global, local or absolute address), because the compiler output is not totally consistent.
I think that we will have to choose between speed or completeness if we reduce the number of cases.
Anyway, I'll have a look to see if I can improve the situation for bitfields-bits, bitfields-checks, bitfields-nibbles.
For bitfields-bits I think there are some ways to reduce the number of tests without sacrificing completeness:
I can remove the cases of preBits = 16 (or even 8 bits), because I think it makes no difference to generated code, but I can't say for sure if this is true for all targets.
This will reduce the total tests by 1/3 for each removed preBits case.
I can also separate the functions:
bits_check_value_no_cast
bits_check_value
to another separate test with far less cases.
Then replace them in this file with much simpler versions using a cast to a type like:
applied to the variable of the original struct type:
This way the checks for the whole bits pack could be done in just one comparison:
instead of 8 of these:
This should speed it up by a factor of more than eight.
I also suggest to make this test portable by using different types for the bitfields: The C standard only mandates support for int, signed int, unsigned int, bool. While unsigned char currently kind of works in sdcc, I think there are some problematic corner cases (and we have no guarantee that the host compiler will support unsigned char for test-host, though AFAIK gcc and clang do).
I applied several simplifications while trying to not sacrifice rule coverage, nor completeness:
Some obvious tests tested in any previous tests are not tested here (assigning values after casting struct of bitfields to byte).
bitfields-bits has been splitted in two as I said before.
Addresses have been updated to support other ports, following the addresses found in absolute.c .
Bitfilelds use unsigned int as suggested.
bitfields-bits1 has now 2016 tests, simulation time has been reduced to 1/3 of the original.
bitfields-bits2 : 72 tests.
bitfields-checks: 1344 tests.
bitfields-dead-loop: 14 tests.
"bitfields-nibbles" tests 5 different operations for 7 variable types using 2 patterns, so tests add up pretty quickly 70 x number of tests, I will see what I can do.
Thanks. With minor modifications, these 4 are now in [r12210].
New bitfields-nibbles2.c with reduced number of cases.
(To execute the full test, uncomment the line with: #define FULL_TEST)
Disabled absolute addressing tests for:
-mcs51
-ds390
Disabled completely because of lack of memory (and also absolute absolute addressing issues):
-pdk
No problems expected with bitfields order (PPC & SPARC).
Last edit: Visenri 2021-05-23
Diff:
Related
Patches:
#362In [r12405] now also the last part has been put into trunk.