On Sat, Oct 28, 2023 at 9:45 PM Richard Henderson <[email protected]> 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
