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 2/3][AArch64] Improve zero extend


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.


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