On 20/07/16 14:08, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> I'm not sure about this, while rtx_cost is called recursively as it
>> walks the RTL, I'd normally expect the outer levels of the recursion to
>> catch the cases where zero-extend is folded into a more complex
>> operation. Hitting a case like this suggests that something isn't doing
>> that correctly.
>
> As mentioned, the query is about an non-existent instruction, so the existing
> rtx_cost code won't handle it. In fact there is no other check for "outer"
> anywhere
> in aarch64_rtx_cost. We either assume outer == SET or know that if it isn't,
> the
> expression will be split.
>
>> So what was the top-level RTX passed into rtx_cost? I'd like to get a
>> better understanding about the use case before acking this patch.
>
> An example would be:
>
> long f(unsigned x) { return (long)x * 20; }
>
> Combine tries to merge the constant into the multiply, so we get this cost
> query:
>
> (mult:DI (zero_extend:DI (reg/v:SI 74 [ x ]))
> (const_int 20 [0x14]))
>
> Given this is not a legal multiply, rtx_mult_cost recurses, assuming both the
> zero_extend and the immediate are going to be split off. But then the
> zero_extend
> is a SET, ie. a zero-cost operation. So not checking outer is correct.
>
> Wilco
>
Why does combine care what the cost is if the instruction isn't valid?
R.
