This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ColdFire softfloat optimization


>> I believe this optimization is valid for all well-formed values and
>> constants, and would be keyed off of -funsafe-math-optimzations.
>
>It probably needs to key off -msoft-float also.  This is unlikely to be 
>a win on any target with FP hardware, as the cost of moving values from 
>the FP regs to the integer regs would be much higher than the cost of an 
>FP compare.

I was thinking that -msoft-float would be the only case where this
would really win, but for ColdFire, if the single precision value is
in memory(such as a parameter to a function), then it is cheaper in
both time and space to compare for equality to 1.0f with:

     move.l #0x7f8000000,%d0
     cmp.l <ea>,%d0
     beq.s L1

than:

     moveq.l #0x7f800000,%d0
     fmove.s %d0,%fp0
     fcmp.s <ea>,%fp0
     fbeq.s L1
     
Where <cnd1> and <cnd2> are judiciously picked depending on the
particular comparison.  The first sequence consumes 5 words and the
second sequence consumes 8 words. 

Of course comparing for equality with floating point numbers is not
really smart FP programming, but it illistrates the point.

Also remember that the ColdFire FPU can't deal with immeidiat
values(they all have to be loaded from memory or from a register).

-- 
Peter Barada
peter@the-baradas.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]