This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] widening_mul: Do cost check when propagating mult into plus/minus expressions
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 14 Jul 2011 11:10:36 +0200
- Subject: Re: [PATCH] widening_mul: Do cost check when propagating mult into plus/minus expressions
- References: <20110713131305.GA5348@bart> <4E1DCEA0.5080007@redhat.com>
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-