On 2023/9/2 01:48, Richard Henderson wrote:
On 9/1/23 10:28, Jiajie Chen wrote:
On 2023/9/2 01:24, Richard Henderson wrote:
On 9/1/23 02:30, Jiajie Chen wrote:
Signed-off-by: Jiajie Chen <c...@jia.je>
---
tcg/loongarch64/tcg-target-con-set.h | 1 +
tcg/loongarch64/tcg-target.c.inc | 60
++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
diff --git a/tcg/loongarch64/tcg-target-con-set.h
b/tcg/loongarch64/tcg-target-con-set.h
index 37b3f80bf9..d04916db25 100644
--- a/tcg/loongarch64/tcg-target-con-set.h
+++ b/tcg/loongarch64/tcg-target-con-set.h
@@ -31,4 +31,5 @@ C_O1_I2(r, 0, rZ)
C_O1_I2(r, rZ, ri)
C_O1_I2(r, rZ, rJ)
C_O1_I2(r, rZ, rZ)
+C_O1_I2(w, w, wJ)
Notes for improvement: 'J' is a signed 32-bit immediate.
I was wondering about the behavior of 'J' on i128 types: in
tcg_target_const_match(), the argument type is int, so will the
higher bits be truncated?
The argument is int64_t val.
The only constants that we allow for vectors are dupi, so all higher
parts are the same as the lower part.
Consider the following scenario:
cmp_vec v128,e32,tmp4,tmp3,v128$0xffffffffffffffff
cmp_vec v128,e32,tmp4,tmp3,v128$0xfffffffefffffffe
cmp_vec v128,e8,tmp4,tmp3,v128$0xfefefefefefefefe
When matching constant constraint, the vector element width is unknown,
so it cannot decide whether 0xfefefefefefefefe means e8 0xfe or e16 0xfefe.
Besides, tcg_target_const_match() does not know the vector element
width.
No, it hadn't been required so far -- there are very few vector
instructions that allow immediates.
r~
