On 07/31/2015 09:01 AM, Alex Bennée wrote:
Aurelien Jarno <aurel...@aurel32.net> writes:
Implement real ext_i32_i64 and extu_i32_i64 ops. They ensure that a
32-bit value is always converted to a 64-bit value and not propagated
through the register allocator or the optimizer.
Cc: Andrzej Zaborowski <balr...@gmail.com>
Cc: Alexander Graf <ag...@suse.de>
Cc: Blue Swirl <blauwir...@gmail.com>
Cc: Claudio Fontana <claudio.font...@huawei.com>
Cc: Claudio Fontana <claudio.font...@gmail.com>
Cc: Richard Henderson <r...@twiddle.net>
Cc: Stefan Weil <s...@weilnetz.de>
Signed-off-by: Aurelien Jarno <aurel...@aurel32.net>
---
tcg/aarch64/tcg-target.c | 4 ++++
tcg/i386/tcg-target.c | 5 +++++
tcg/ia64/tcg-target.c | 4 ++++
tcg/ppc/tcg-target.c | 6 ++++++
tcg/s390/tcg-target.c | 5 +++++
tcg/sparc/tcg-target.c | 8 ++++++--
tcg/tcg-op.c | 10 ++++------
tcg/tcg-opc.h | 3 +++
tcg/tci/tcg-target.c | 4 ++++
tci.c | 6 ++++--
10 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index b7ec4f5..7f7ab7e 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -1556,6 +1556,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_ext16s_i32:
tcg_out_sxt(s, ext, MO_16, a0, a1);
break;
+ case INDEX_op_ext_i32_i64:
case INDEX_op_ext32s_i64:
tcg_out_sxt(s, TCG_TYPE_I64, MO_32, a0, a1);
break;
@@ -1567,6 +1568,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_ext16u_i32:
tcg_out_uxt(s, MO_16, a0, a1);
break;
+ case INDEX_op_extu_i32_i64:
case INDEX_op_ext32u_i64:
tcg_out_movr(s, TCG_TYPE_I32, a0, a1);
So what is the difference between extu_i32_i64 and ext32u_i64. The
README skips over this particular part of the naming convention and I
wonder if we should be clearer about that before we add more ops.
The size of the input, for one. The possibility of eliding is another.
Our current plan for x86_64 and aarch64 is to canonicalize all 32-bit
quantities to be zero-extended in the register. Primarily because for both
platforms this can be done for free. Thus exts_i32_64 and extrl_i64_i32 will
require implementation, but extu_i32_i64 will be replaced by a move.
Similarly, mips64 would keep values sign-extended (as *required* by the
standard for all 32-bit operations), and thus exts_i32_i64 would be replaced by
a move.
Other targets will probably make extrl_i64_i32 be the move, since the 32-bit
ops don't re-extend for free.
r~
