Re: [PATCH] widening_mul: Do cost check when propagating mult into plus/minus expressions

[Georg-Johann Lay <avr at gjlay dot de>]

Richard Guenther wrote:
> On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
> <krebbel@linux.vnet.ibm.com> wrote:
>> Hi,
>>
>> the widening_mul pass might increase the number of multiplications in
>> the code by transforming
>>
>> a = b * c
>> d = a + 2
>> e = a + 3
>>
>> into:
>>
>> d = b * c + 2
>> e = b * c + 3
>>
>> under the assumption that an FMA instruction is not more expensive
>> than a simple add.  This certainly isn't always true.  While e.g. on
>> s390 an fma is indeed not slower than an add execution-wise it has
>> disadvantages regarding instruction grouping.  It doesn't group with
>> any other instruction what has a major impact on the instruction
>> dispatch bandwidth.
>>
>> The following patch tries to figure out the costs for adds, mults and
>> fmas by building an RTX and asking the backends cost function in order
>> to estimate whether it is whorthwhile doing the transformation.
>>
>> With that patch the 436.cactus hotloop contains 28 less
>> multiplications than before increasing performance slightly (~2%).
>>
>> Bootstrapped and regtested on x86_64 and s390x.
> 
> Ick ;)
> 
> Maybe this is finally the time to introduce target hook(s) to
> get us back costs for trees?  For this case we'd need two
> actually, or just one - dependent on what finegrained information
> we pass.  Choices:
> 
>   tree_code_cost (enum tree_code)
>   tree_code_cost (enum tree_code, enum machine_mode mode)
>   unary_cost (enum tree_code, tree actual_arg0) // args will be mostly
> SSA names or constants, but at least they are typed - works for
> mixed-typed operations
>   binary_cost (...)
>   ...
>   unary_cost (enum tree_code, enum tree_code arg0_kind) // constant
> vs. non-constant arg, but lacks type/mode
> 
> Richard.

What's bad with rtx_costs?

Yet another cost function might duplicate cost computation in a backend --
once on trees and once on RTXs.

BTW: For a port I read rtx_costs from insn attributes which helped me to
clean up code in rtx_costs to a great extend.  In particular for a target
with complex instructions which are synthesized by insn combine, rtx_costs
is mostly mechanical and brain-dead retyping of bulk of code that is
already present almost identical in insn-recog.c.

Johann