Bug 509572

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.