On Wed, 22 May 2024 12:02:26 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/22/24 12:15 PM, Palmer Dabbelt wrote:
On Wed, 22 May 2024 11:01:16 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/22/24 6:47 AM, Jivan Hakobyan wrote:
After 8367c996e55b2 commit several checks on round_32.c test started to
fail.
The reason is that we prevent rounding DF->SI->DF on RV32 and instead of
a conversation sequence we get calls to appropriate library functions.
gcc/testsuite/ChangeLog:
* testsuite/gcc.target/riscv/round_32.c: Fixed test
I wonder if this test even makes sense for rv32 anymore given we can't
do a DF->DI as a single instruction and DF->SI is going to give
incorrect results. So the underlying optimization to improve those
rounding cases just doesn't apply to DF mode objects for rv32.
Thoughts?
Unless I'm missing something, we should still be able to do the float
roundings on rv32?
I initially thought that as well. The problem is we don't have a DF->DI
conversion instruction for rv32. We can't use DF->SI as the range of
representable values is wrong.
Ya, right. I guess we'd need to be calling roundf(), not round(), for
those? So maybe we should adjust the tests to do that?
I think with Zfa we'd also have testable sequences for the double/double
and float/float roundings, which could be useful to test. I'm not
entirely sure there, though, as I always get a bit lost in which FP
rounding flavors map down.
Zfa is a different story as it has instructions with the proper
semantics ;-) We'd just emit those new instructions and wouldn't have
to worry about the initial range test.
and I guess that'd just be an entirely different set of scan-assembly
sets than round_32 or round_64, so maybe it's not a reason to keep these
around.
I'd also kicked off some run trying to promote these to executable
tests. IIRC it was just DG stuff (maybe just adding a `dg-do run`?)
but I don't know where I stashed the results...
Not a bad idea, particularly if we test the border cases.
Ya, makes sense -- I guess the current values aren't that exciting for
execution, but we could just add some more interesting ones...
jeff
