This is the mail archive of the gcc-patches@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: [PATCH] widening_mul: Do cost check when propagating mult into plus/minus expressions


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-


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