On 19/07/16 16:31, Wilco Dijkstra wrote:
> When zero extending a 32-bit value to 64 bits, there should always be a
> SET operation on the outside, according to the patterns in aarch64.md.
> However, the mid-end can also ask for the cost of a made-up instruction,
> where the zero-extend is part of another operation, not SET.
>
> In this case we currently cost the zero extend operation as a uxtb/uxth.
> Instead, cost it the same way we cost "normal" 32-to-64-bit zero
> extends: as a "mov" or the cost of the inner operation.
>
> Bootstrapped and tested on aarch64-none-elf.
>
> 2016-07-19 Kristina Martsenko <kristina.martse...@arm.com>
>
> * config/aarch64/aarch64.c (aarch64_rtx_costs): Fix cost of zero extend.
>
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.
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.
A test-case would be really useful here, even if it can't be used in the
testsuite.
R.
> ---
> gcc/config/aarch64/aarch64.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index
> bddffc3ab28cde3a996fd13c060de36227315fb5..a2621313d3278d39db0f1d5640b33201efefac21
> 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -6421,12 +6421,11 @@ cost_plus:
> a 'w' register implicitly zeroes the upper bits of an 'x'
> register. However, if this is
>
> - (set (reg) (zero_extend (reg)))
> + (zero_extend (reg))
>
> we must cost the explicit register move. */
> if (mode == DImode
> - && GET_MODE (op0) == SImode
> - && outer == SET)
> + && GET_MODE (op0) == SImode)
> {
> int op_cost = rtx_cost (op0, VOIDmode, ZERO_EXTEND, 0, speed);
>
>
