Re: [PATCH v2 00/35] tcg: Introduce TCG_COND_TST{EQ,NE}

[Paolo Bonzini]

On Sat, Oct 28, 2023 at 9:45 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Expose a pair of comparison operators that map to the "test"
> comparison that is available on many architectures.
>
> Changes for v2:
>   * Add TCGCond to tcg_target_const_match.
>     This fixes a long-standing issue with ppc and s390x backends,
>     in that CMPI for signed comparisons has signed immediate and
>     CMPLI for unsigned comparisons has unsigned immediate.
>     But now allows different immediates for the TST comparisons.
>   * tcg/i386: Generate TEST x,x for power-of-two in {7,15,31,63}.
>   * tcg/i386: Generate BT n,x for other power-of-two.
>   * tcg/ppc: tcg_target_const_match improvements
>   * tcg/s390x: tcg_target_const_match improvements
>   * target/m68k: Use TST{EQ,NE} for gen_fcc_cond.

I updated the MIPS backend (untested though) and pushed the result to
branch i386 of https://gitlab.com/bonzini/qemu/.

However I was thinking: a lot of RISC targets simply do AND/ANDI
followed by the sequence used for TCG_COND_NE.  Would it make sense to
have a TCG_TARGET_SUPPORTS_TST bit and, if absent, lower TSTEQ/TSTNE
to AND+EQ/NE directly in the optimizer?  And for brcond2/setcond2,
always using AND/AND/OR may work just as well as any backend-specific
trick, and will give more freedom to the register allocator.

This also would allow to reorder the target patches before the TCG
patches, thus: 1) providing more exposure to the lowering code 2)
making the "minimum viable series" smaller. (2) is not a huge deal
since you have already written the backend code, but (1) is
interesting.

Paolo