https://bugs.kde.org/show_bug.cgi?id=509572
Bug ID: 509572
Summary: s390x: Overhaul BFP testsuite
Classification: Developer tools
Product: valgrind
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
I plan to overhaul BFP testcases.
The key observation (and that is no surprise at all) is that for
many BFP insns the following holds:
If guest code contains BFP insn XYZ then at the end of the VEX pipeline
insn XYZ will be emitted for it. We also know that the IR optimisers won't
touch floating point IROps.
Today our testing looks like this (from fpconv.stdout.exp):
----- int32_t -> double
cdfbr 0 -> 0.000000
cdfbr 1 -> 1.000000
cdfbr -1 -> -1.000000
cdfbr 42 -> 42.000000
cdfbr 32767 -> 32767.000000
cdfbr -32768 -> -32768.000000
cdfbr 2147483647 -> 2147483647.000000
cdfbr -2147483648 -> -2147483648.000000
This is not interesting at all. We're not interested
- to verify that hardware works correctly
- to find suitable width and precision for printf format strings (depending
on the floating point value)
- finding bugs in printf implementation
In other words, all those values above are boring.
What we *do* want to know is whether for a given BFP insn XYZ the
very same insn is emitted in the end.
How do we do that? Using cdfbr as the example:
1) Create a testcase template:
auxprogs/s390-runone -t > foo.c
2) Replace the FIXME line with an asm stmt containing the insn we want to test:
sed -i "s/^.*FIXME.*/ asm volatile (\"cdfbr %f0,%f1\");/" foo.c
3) Compile foo.c into an executable "foo" not requiring the dynamic
loader. The executable will have exactly one superblock.
auxprogs/s390-runone foo.c
4) Run valgrind, trace IR generation and assembly and filter the output:
coregrind/valgrind --tool=none --trace-notbelow=0 --trace-flags=10000001
./foo 2>&1 | egrep "(Front|Assembly|cdfbr)"
This will print:
------------------------ Front end ------------------------
cdfbr %f0,%r1
------------------------ Assembly ------------------------
cdfbr %f7,%r5
Voila.
For non-commutative binary operators having testcases that write out register
contents is a good thing because it allows to find operand order errors.
Everything I said about BFP also holds for DFP.
And I bet it also holds for other architectures.
--
You are receiving this mail because:
You are watching all bug changes.
