Re: [RFC PATCH v1 04/43] tcg: Add gvec functions for creating consant vectors

[Anton Johansson]

On 22/11/24, Richard Henderson wrote:
> On 11/20/24 19:49, Anton Johansson wrote:
> > This commit adds a gvec function for copying data from constant array
> > given in C to a gvec intptr_t.  For each element, a host store of
> > each constant is performed, this is not ideal and will inflate TBs for
> > large vectors.
> > 
> > Moreover, data will be copied during each run of the generated code
> > impacting performance.  A more suitable solution might store constant
> > vectors separately, this can be handled either on the QEMU or
> > helper-to-tcg side.
> > 
> > Signed-off-by: Anton Johansson <anjo@rev.ng>
> 
> This is invalid because generic code does not know how to index elements
> within the target vector, which this is doing with its per-element copy.

Hmm I should take a look at tcg_gen_gvec_dup_imm() again, isn't it doing
basically the same thing?

> The code in target/arch/ knows the element ordering (though I suspect you
> have not taught llvm), and could arrange for the data to be put in the
> correct byte order, which could then be copied into place using plain host
> vector operations.  I won't attempt to riff on what such an interface would
> look like exactly, but I imagine that something sensible could be
> constructed with only a little effort.

I might have misunderstood how gvec works, I thought all elements would
be in host order, and so copying from a host C array would be fine?

//Anton