qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [RFC PATCH 3/9] tcg: generate ptrs to vector


From: Richard Henderson
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC PATCH 3/9] tcg: generate ptrs to vector registers
Date: Thu, 17 Aug 2017 13:13:07 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 08/17/2017 11:03 AM, Alex Bennée wrote:
> As we operate directly on the vectors in memory we pass around the
> address for TCG_TYPE_VECTOR. Currently only helpers ever see these
> values but if we were to generate simd backend instructions they would
> load directly from the backing store.
> 
> We also need to ensure when copying from one temp register to the
> other the right size is used.
> 
> Signed-off-by: Alex Bennée <address@hidden>
> ---
>  tcg/tcg.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 35598296c5..e16811d68d 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -2034,7 +2034,21 @@ static void temp_load(TCGContext *s, TCGTemp *ts, 
> TCGRegSet desired_regs,
>          break;
>      case TEMP_VAL_MEM:
>          reg = tcg_reg_alloc(s, desired_regs, allocated_regs, 
> ts->indirect_base);
> -        tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset);
> +        if (ts->type == TCG_TYPE_VECTOR) {
> +            /* Vector registers are ptr's to the memory representation */
> +            TCGArg args[TCG_MAX_OP_ARGS];
> +            int const_args[TCG_MAX_OP_ARGS];
> +            args[0] = reg;
> +            args[1] = ts->mem_base->reg;
> +            args[2] = ts->mem_offset;
> +            const_args[0] = 0;
> +            const_args[1] = 0;
> +            const_args[2] = 1;
> +            /* FIXME: needs to by host_ptr centric */
> +            tcg_out_op(s, INDEX_op_add_i64, args, const_args);

This fails when the offset is out of range for the addition, and technically if
the backend does not support 3-operand addition.  You didn't see this because
the x86 backend does use lea, and has a 32-bit offset.

Once upon a time we had a tcg_out_addi; if we go this way with TCG_TYPE_VECTOR,
we should re-introduce that.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]