On 28.02.19 17:34, Richard Henderson wrote:
> On 2/27/19 11:48 PM, David Hildenbrand wrote:
>> I think that would be wrong. It is only an alignment hint.
>>
>> "Setting the alignment hint to a non-zero value
>> that doesn’t correspond to the alignment of the second operand may
>> reduce performance
On 2/27/19 11:48 PM, David Hildenbrand wrote:
> I think that would be wrong. It is only an alignment hint.
>
> "Setting the alignment hint to a non-zero value
> that doesn’t correspond to the alignment of the second operand may
> reduce performance on some models."
>
> So we must not inject an ex
On 27.02.19 16:39, Richard Henderson wrote:
> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>> +static DisasJumpType op_vl(DisasContext *s, DisasOps *o)
>> +{
>> +load_vec_element(s, TMP_VREG_0, 0, o->addr1, MO_64);
>> +gen_addi_and_wrap_i64(s, o->addr1, o->addr1, 8);
>> +load_vec_elemen
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vl(DisasContext *s, DisasOps *o)
> +{
> +load_vec_element(s, TMP_VREG_0, 0, o->addr1, MO_64);
> +gen_addi_and_wrap_i64(s, o->addr1, o->addr1, 8);
> +load_vec_element(s, TMP_VREG_0, 1, o->addr1, MO_64);
> +gen_gv
When loading from memory, load to our temporary vector first, so in case
we get an access exception on the second 64 bit element, the vector
won't get modified.
Loading with strange alingment from the end of the address space will
not properly wrap, we can ignore that for now.
Signed-off-by: Davi
