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-
