riscv64: Restore the IR types 7576d04 widened

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

7576d04 ("riscv: fix instructions that use the unsupported Ity_1 data type") widened three
Ity_I1 temporaries to Ity_I64/Ity_I32 without adapting what is assigned to them, so six
instruction forms now fail the IR sanity check and libVEX reports the whole block as
Ijk_NoDecode:

• sc.w / sc.d. IRStmt_LLSC's result type is fixed by the IR contract:
  pub/libvex_ir.h says "STOREDATA != NULL (SC): transfer type = type of STOREDATA, and
  RESULT :: Ity_I1". Widening the temp makes the statement itself invalid, and no other
  encoding of a store-conditional exists. guest_arm64_toIR.c builds the same sequence with
  Ity_I1 and Iop_1Uto64, which is what this restores.
• feq.s / flt.s / feq.d / flt.d. Their Iop_CmpEQ32 yields Ity_I1 into an Ity_I32
  temp. The fle case in the same switch already wraps its comparisons in Iop_1Uto32; feq
  and flt now do the same.

Before, on master:

sc.d a3, a1, (s2)   af36b918   size=0 jumpkind=Ijk_NoDecode
sc.w a3, a1, (s2)   af26b918   size=0 jumpkind=Ijk_NoDecode
feq.s a0, fa0, fa1  5325b5a0   size=0 jumpkind=Ijk_NoDecode
flt.s a0, fa0, fa1  5315b5a0   size=0 jumpkind=Ijk_NoDecode
feq.d a0, fa0, fa1  5325b5a2   size=0 jumpkind=Ijk_NoDecode
flt.d a0, fa0, fa1  5315b5a2   size=0 jumpkind=Ijk_NoDecode
fle.s a0, fa0, fa1  5305b5a0   size=4 jumpkind=Ijk_Boring

with vex: the 'impossible' happened: sanityCheckFail: exiting due to bad IR and
ERROR = Ist.LLSC(SC).result: not :: Ity_I1 on stderr. After, all six decode.

The visible cost is in angr: a RISC-V block that runs into one of these becomes undecodable
bytes, and CFGFast's linear scan then restarts two bytes into the four-byte instruction, so
blocks begin in the middle of instructions. Over a corpus sweep this accounted for the whole
RISC-V share of that symptom.

Consumed by angr/pyvex#566, which carries the regression tests. Fixes angr/pyvex#516,
whose diagnosis covers flt only.

Validation: angr/pyvex#566 (comment)

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Efficacy on a real RISC-V binary

Recorded here as well as on angr/pyvex#566, since the decode change itself lives in this
pull request. A corpus sweep surfaced a RISC-V object that exercises these encodings heavily:
a libpixman-1.so.46.4 from an OpenBSD riscv64 userland, 2,458,360 bytes, sha256
5be22893b2321704.... With angr at 0c293dc0d and CFGFast(normalize=True, data_references=False, resolve_indirect_jumps=True, force_complete_scan=False), scored
against the object's own DWARF line table, symbol table and .eh_frame:

	before	after
instructions VEX refuses, of 99,222 in 902 sized function symbols	2,730	0
DWARF line addresses no block covers, of 42,743	12,030	1
sized function symbols no block covers at all, of 902	29	0
.eh_frame FDE starts no block covers, of 902	29	0
block starts mid-instruction of a cleanly decoding function	144	0
symbol-function bytes covered, of 303,842	212,864	303,838
blocks	12,279	18,120

The 2,730 refusals are flt.s (2,048), flt.d (597) and feq.d (85); nothing else in the
object fails to lift.

The reason the cost is so far above the instruction count: the failure discards the whole
IRSB. Lifting from 0x41ac88 returns Ijk_NoDecode with size 0 even though the first
nineteen instructions decode -- flt.d is instruction #19, and max_inst=19 gives size 64
while max_inst=20 gives size 0. So each bad instruction also loses up to a block's worth of
good ones ahead of it, and CFGFast then has nothing to continue from.

No-harm on a 196-object linked-ELF sample carrying symbol, line and unwind evidence, same
worktree: exactly one row differs, a RISCV64 object gaining one block, no truth counter
changed, no new error or timeout.