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.
