[llvm-dev] getScalarizationOverhead()
Simon Pilgrim via llvm-dev
llvm-dev at lists.llvm.org
Sun Jan 22 08:07:27 PST 2017
> On 20 Jan 2017, at 14:53, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
> On 01/20/2017 08:30 AM, Jonas Paulsson wrote:
>>
>>
>> On 2017-01-20 14:31, Hal Finkel wrote:
>>>
>>> On 01/20/2017 06:11 AM, Jonas Paulsson via llvm-dev wrote:
>>>> Hi,
>>>>
>>>> I wonder why getScalarizationOverhead() does not take into account the number of operands of the instruction? This should influence the number of extracts needed, so instead of
>>>>
>>>> Scalarization cost = NumEls * (insert + extract)
>>>>
>>>> it would be better to do
>>>>
>>>> Scalarization cost = NumEls * (insert + (extract * numOperands))
>>>
>>> I suspect this is an oversight (although we need to be a bit careful here because if two operands are the same, which is not uncommon, we don't want to double the cost).
>>>
>>> -Hal
>>
>> Do you in those cases of an identical operand want to count just a cost of "1" for a register move, instead of the "extraction cost"?
>
> There should be no cost to reusing the operand. (mul a, a) should only extract a once, the fact that it is used twice should not increase the cost.
>
> -Hal
There appears to be a similar issue within the x86 AVX1 cost tables for cases where we have to split the 256-bit integer operations. Some binops add 1*extract_subvector + 1*insert_subvector to the 2*128-binop costs whilst others don’t bother adding anything at all. We need to try harder to determine if we should add 1 (duplicate input or constant folded extract) or 2 extracts to the final cost.
More information about the llvm-dev
mailing list