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

[Richard Henderson <richard.henderson@linaro.org>]

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~