https://bugs.kde.org/show_bug.cgi?id=385055
--- Comment #4 from Julian Seward <jsew...@acm.org> --- (In reply to Carl Love from comment #2) > perhaps use > a C-code handler in place of the generate_store_FPRF() function. That's probably your best option. Alternatively (and as a general comment), generate_store_FPRF() and its sub functions (is_NaN, .., is_Denorm, create_FPCC, etc) use Ity_I1 to do boolean functions (and, or, not). I can see why you'd want to do that -- it's conceptually clean -- but it generates huge numbers of I1 <-> I32 conversions in the IR, of the form 1Uto32(32to1(And32(1Uto32(t130),1Uto32(t129)) Those are expensive in the back end, especially 1Uto32/1Uto64. It would be less verbose to re-do all of these functions to return I32s which are either 0 or 1. Then a lot of those conversions would disappear. One other comment .. I noticed in exponent_compare(), this: /* No support for 64-bit compares in 32-bit mode, need to do upper * and lower parts using 32-bit compare operators. */ There's no intrinsic reason why you can't support CmpEQ64 in 32-bit mode. The ppc back end already has routines to compute 64 bit values into a 32-bit register pair (iselInt64Expr) and you could then implement CmpEQ64/NE64 as the x86 (32-bit) backend does. -- You are receiving this mail because: You are watching all bug changes.