Age | Commit message (Collapse) | Author |
|
These tests all depend on generating arbitrarily long (>64-bit) integers.
It would be possible to have these tests work in this case I think, as the
results are always masked to shorter values. But quite fiddly. So just
rename them so they are automatically skipped if the target doesn't have
big int support.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
|
|
This commit reworks the Viper pointer boundary tests in order to make
them more accurate and easier to extend.
The tests are now easier to reason about in their output, using easier
to read values, and bit thresholds are now more configurable. If a new
conditional code sequence is introduced, adding a new bit threshold is
just a matter of adding a value into a tuple at the beginning of the
relevant test file.
Load tests have also been made more accurate, with better function
templates to test register-indexed operations.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|
|
This commit adds a series of test cases to exercise the Viper code
generator load/store emitting capabilities on certain boundary
conditions.
The new test cases check whether the emitted load/store code performs
correctly when dealing with specific memory offsets, which trigger
specific code generation sequences on different architectures.
Right now the cases are for unsigned offsets whose bitmasks span up to
5, 8, and 12 bits (respectively Arm/Thumb, Xtensa, RV32).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
|