On 07/13/2011 06:58 PM, Richard Henderson wrote: > Why the force_operand? You've got register inputs. Either the target > is going to support the operation or it isn't. > Seems to me you can check the availability of the operation in the > optab and pass that gen_rtx_fmt_ee result to rtx_cost directly.
Do I really need to check optab for availability at this point? For FMA convert_mult_to_fma already did the check. But what to do if no optab is available for add/mul? Assume extraordinary high costs? This probably wouldn't make sense since it would make a mul or add more expensive than an fma. Or perhaps the rtx_cost hooks should handle that by returning high costs for everything the backend is not able to implement directly? >> + bool speed = optimize_bb_for_speed_p (gimple_bb (mul_stmt)); >> + static unsigned mul_cost[NUM_MACHINE_MODES]; >> + static unsigned add_cost[NUM_MACHINE_MODES]; >> + static unsigned fma_cost[NUM_MACHINE_MODES]; > ... >> + if (!fma_cost[mode]) >> + { >> + fma_cost[mode] = compute_costs (mode, FMA, speed); >> + add_cost[mode] = compute_costs (mode, PLUS, speed); >> + mul_cost[mode] = compute_costs (mode, MULT, speed); >> + } > > Saving cost data dependent on speed, which is non-constant. > You probably need to make this a two dimensional array. Right. I'll fix this. Bye, -Andreas-