On Mon, Oct 12, 2026 at 5:38 PM Takayuki 'January June' Suwa <[email protected]> wrote: > > -- TARGET_FLOAT32/64 @ xtensa.h > Is it possible to configure XCHAL_HAVE_DFP without configuring XCHAL_HAVE_FP?
This is not possible, only the reverse: DFPU coprocessor that provides only single precision registers and operations. Which is identical to the current xtensa FPU model + TARGET_HARD_FLOAT_POSTINC. > If so, providing patterns that emulate SFmode operations using DFmode ones > might be advantageous compared to falling back to the SFmode softmath library. > > -- TARGET_HARD_FLOAT_CONST @ xtensa.h > Is CONST.D available when TARGET_FLOAT32_*s are true and TARGET_FLOAT64_*s > are false? No, it's not. It's only available when TARGET_FLOAT64_*s are true. But I believe there's no way for the const.d to be generated then. > Similarly, is CONST.S available when TARGET_FLOAT32_*s are false and > TARGET_FLOAT64_*s are true? This configuration (TARGET_FLOAT32_*s are false and TARGET_FLOAT64_*s are true) is again not possible, TARGET_FLOAT32_*s will be true when TARGET_FLOAT64_*s are true. > -- movdf_internal @ xtensa.md > It would be advantageous to have an alternative to assigning the constant 0.0 > to an address register pair: > "movi a3, 0; movi a2, 0" > is faster and smaller than > "const.d f0, 0" followed by "rfrd a3, f0; rfr a2, f0" > > -- movdf_internal @ xtensa.md > The instructions corresponding to "df-load-a-from-T\t%0, %1" consist of two > pairs, each comprising an L32R instruction (3 bytes) and a literal pool entry > (4 bytes). > > -- xtensa_class_max_nregs() @ xtensa.cc > Addressed the issue where DFmode register number allocation for the FP_REGS > register class skipped every other register. Thanks for these fixes. -- Thanks. -- Max
