diff options
Diffstat (limited to 'results/classifier/118/all/1759264')
| -rw-r--r-- | results/classifier/118/all/1759264 | 248 |
1 files changed, 248 insertions, 0 deletions
diff --git a/results/classifier/118/all/1759264 b/results/classifier/118/all/1759264 new file mode 100644 index 000000000..61129a116 --- /dev/null +++ b/results/classifier/118/all/1759264 @@ -0,0 +1,248 @@ +peripherals: 0.980 +hypervisor: 0.978 +permissions: 0.972 +performance: 0.970 +device: 0.969 +arm: 0.967 +semantic: 0.967 +architecture: 0.965 +PID: 0.964 +debug: 0.964 +graphic: 0.964 +vnc: 0.963 +register: 0.962 +assembly: 0.961 +user-level: 0.961 +boot: 0.959 +socket: 0.959 +kernel: 0.955 +risc-v: 0.954 +ppc: 0.951 +virtual: 0.949 +VMM: 0.946 +files: 0.944 +TCG: 0.939 +KVM: 0.937 +x86: 0.919 +network: 0.918 +mistranslation: 0.918 +i386: 0.825 + +fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns + +After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered. + +helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity. + +The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However, +I'm not sure if this breaks other targets and I have no easy way to test it. + +Yeah it looks like it was missed, the round_to_uint code does it. + +Do you have a test case I can verify? + +On 04/10/2018 10:07 PM, Alex Bennée wrote: +> Yeah it looks like it was missed, the round_to_uint code does it. +> +> Do you have a test case I can verify? +> + +For the NaN input 0xffffffff the expected result for the flags is that +flag_invalid is raised. + +I can provide you with some TriCore asm, but it is a bit of pain to get +the gnu assembler to build, since the public version is a decade old. + +Cheers, +Bastian + + + +Bastian Koppelmann <email address hidden> writes: + +> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>> Yeah it looks like it was missed, the round_to_uint code does it. +>> +>> Do you have a test case I can verify? +>> +> +> For the NaN input 0xffffffff the expected result for the flags is that +> flag_invalid is raised. +> +> I can provide you with some TriCore asm, but it is a bit of pain to get +> the gnu assembler to build, since the public version is a decade old. + +I'll trust you if you send me a static binary for this particular +verification ;-) + +It would be nice to TriCore tests building in tests/tcg/ but I guess we +need an up to date cross compile environment somewhere. + +> +> Cheers, +> Bastian + + +-- +Alex Bennée + + +On 04/11/2018 01:01 PM, Alex Bennée wrote: +> +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>> +>>> Do you have a test case I can verify? +>>> +>> +>> For the NaN input 0xffffffff the expected result for the flags is that +>> flag_invalid is raised. +>> +>> I can provide you with some TriCore asm, but it is a bit of pain to get +>> the gnu assembler to build, since the public version is a decade old. +> +> I'll trust you if you send me a static binary for this particular +> verification ;-) +> +> It would be nice to TriCore tests building in tests/tcg/ but I guess we +> need an up to date cross compile environment somewhere. + +That is the problem. There is a gcc/binutils port done by some german +company. And it's not easy to get the source. The one they provide is +pretty old and needs some patching to get in building on modern +machines. Right now I'm trying to set up a test environment. + +Cheers, +Bastian + + +On 04/11/2018 01:01 PM, Alex Bennée wrote: +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>> +>>> Do you have a test case I can verify? +>>> +>> +>> For the NaN input 0xffffffff the expected result for the flags is that +>> flag_invalid is raised. +>> +>> I can provide you with some TriCore asm, but it is a bit of pain to get +>> the gnu assembler to build, since the public version is a decade old. +> +> I'll trust you if you send me a static binary for this particular +> verification ;-) + +I set up a github repo with working binutils and the corresponding testcase: + +https://github.com/bkoppelmann/tricore-fpu + +The one caveat is, that we cannot produce any binaries with the TriCore +ISA > 1.3. + +In this testcase the last ftoi instruction is supposed to raise the +invalid flag and return 0 since the input was NaN. We did that by only +checking for NaN if any flag was raised after ftoi, then do the NaN +check, and if positive, return 0. + +Cheers, +Bastian + + + +Bastian Koppelmann <email address hidden> writes: + +> On 04/11/2018 01:01 PM, Alex Bennée wrote: +>> Bastian Koppelmann <email address hidden> writes: +>> +>>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>>> +>>>> Do you have a test case I can verify? +>>>> +>>> +>>> For the NaN input 0xffffffff the expected result for the flags is that +>>> flag_invalid is raised. +>>> +>>> I can provide you with some TriCore asm, but it is a bit of pain to get +>>> the gnu assembler to build, since the public version is a decade old. +>> +>> I'll trust you if you send me a static binary for this particular +>> verification ;-) +> +> I set up a github repo with working binutils and the corresponding +> testcase: +> +> https://github.com/bkoppelmann/tricore-fpu +> +> The one caveat is, that we cannot produce any binaries with the TriCore +> ISA > 1.3. +> +> In this testcase the last ftoi instruction is supposed to raise the +> invalid flag and return 0 since the input was NaN. We did that by only +> checking for NaN if any flag was raised after ftoi, then do the NaN +> check, and if positive, return 0. + +Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to +run it. What are the runes for launching the test? + +> +> Cheers, +> Bastian + + +-- +Alex Bennée + + +On 04/12/2018 03:41 PM, Alex Bennée wrote: +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/11/2018 01:01 PM, Alex Bennée wrote: +>>> Bastian Koppelmann <email address hidden> writes: +>>> +>>>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>>>> +>>>>> Do you have a test case I can verify? +>>>>> +>>>> +>>>> For the NaN input 0xffffffff the expected result for the flags is that +>>>> flag_invalid is raised. +>>>> +>>>> I can provide you with some TriCore asm, but it is a bit of pain to get +>>>> the gnu assembler to build, since the public version is a decade old. +>>> +>>> I'll trust you if you send me a static binary for this particular +>>> verification ;-) +>> +>> I set up a github repo with working binutils and the corresponding +>> testcase: +>> +>> https://github.com/bkoppelmann/tricore-fpu +>> +>> The one caveat is, that we cannot produce any binaries with the TriCore +>> ISA > 1.3. +>> +>> In this testcase the last ftoi instruction is supposed to raise the +>> invalid flag and return 0 since the input was NaN. We did that by only +>> checking for NaN if any flag was raised after ftoi, then do the NaN +>> check, and if positive, return 0. +> +> Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to +> run it. What are the runes for launching the test? + +qemu-system-tricore -M tricore_testboard -kernel fpu-test.elf -nographic + +However, this is not really a test. I usually run these against +Infineons golden (sadly proprietary) simulator and compare register +dumps. I have some more regression tests but I haven't had the time make +them into proper tests, such that we don't need this golden model. + +Cheers, +Bastian + + |