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

[Richard Henderson]

On 12/3/24 12:19, Anton Johansson wrote:
> 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?

No, it's limited to replicating uint64_t.

> > 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?

No, they are not.  They are chucked into host-endian uint64_t, but the ordering of the 
uint64_t is specific to target/arch/.  You never know what "index 0" is, logically, even 
knowing host-endian, simply because different targets have different element numberings. 
Especially big-endian targets.


r~