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 <a...@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
