refactor: impl ExtendInto and WrapInto for Self

[yjhmelody]

No description provided.

[Robbepop]

What is the advantage of having ExtendInto compared to a simple From implementation?

[paritytech-cicd-pr]

BENCHMARKS

	NATIVE			WASMTIME
BENCHMARK	MASTER	PR	DIFF	MASTER	PR	DIFF	WASMTIME OVERHEAD
execute/ bare_call_0	1.35ms	1.27ms	🟢 -5.92%	1.13ms	1.12ms	⚪ -0.19%	🟢 -11%
execute/ bare_call_0/typed	706.76µs	699.79µs	⚪ -1.01%	547.01µs	548.78µs	⚪ 0.26%	🟢 -22%
execute/ bare_call_1	1.47ms	1.40ms	🟢 -4.56%	1.39ms	1.37ms	🟢 -0.86%	🟢 -2%
execute/ bare_call_16	3.04ms	3.05ms	🟢 0.14%	5.03ms	4.98ms	🟢 -0.92%	🟡 63%
execute/ bare_call_16/typed	1.34ms	1.32ms	🟢 -1.58%	2.39ms	2.32ms	🟢 -2.85%	🟡 76%
execute/ bare_call_1/typed	844.46µs	800.18µs	🟢 -5.66%	874.50µs	873.20µs	⚪ -0.16%	🟢 9%
execute/ bare_call_4	1.76ms	1.76ms	🟢 0.36%	2.16ms	2.13ms	🟢 -1.18%	🟢 21%
execute/ bare_call_4/typed	934.85µs	892.11µs	🟢 -4.34%	1.01ms	992.68µs	🟢 -1.31%	🟢 11%
execute/ br_table	935.25µs	907.23µs	🟢 -3.01%	1.14ms	1.13ms	⚪ -0.05%	🟢 25%
execute/ count_until	903.56µs	903.59µs	⚪ 0.00%	2.41ms	2.40ms	⚪ -0.08%	🔴 166%
execute/ factorial_iterative	365.05µs	364.76µs	⚪ -0.04%	961.42µs	975.41µs	🔴 1.51%	🔴 167%
execute/ factorial_recursive	724.45µs	802.43µs	🔴 10.63%	1.57ms	1.54ms	🟢 -2.00%	🟡 92%
execute/ fib_iterative	1.79ms	1.79ms	⚪ -0.07%	5.00ms	5.26ms	🔴 5.31%	🔴 194%
execute/ fib_recursive	7.07ms	7.05ms	⚪ -0.14%	14.80ms	14.29ms	🟢 -3.47%	🔴 103%
execute/ global_bump	1.36ms	1.36ms	⚪ 0.03%	3.66ms	3.66ms	⚪ -0.07%	🔴 168%
execute/ global_const	1.00ms	1.00ms	⚪ 0.04%	2.83ms	2.84ms	⚪ 0.35%	🔴 183%
execute/ host_calls	32.66µs	32.66µs	⚪ -0.07%	44.69µs	44.61µs	⚪ -0.27%	🟢 37%
execute/ memory_fill	1.58ms	1.56ms	🟢 -1.40%	4.41ms	4.20ms	🟢 -4.83%	🔴 170%
execute/ memory_sum	1.55ms	1.55ms	⚪ -0.03%	4.18ms	4.19ms	⚪ 0.04%	🔴 170%
execute/ memory_vec_add	3.09ms	3.07ms	⚪ -0.29%	8.78ms	9.05ms	🔴 3.14%	🔴 194%
execute/ recursive_is_even	1.30ms	1.30ms	⚪ 0.48%	2.72ms	2.63ms	🟢 -3.22%	🔴 102%
execute/ recursive_ok	171.01µs	171.04µs	⚪ -0.61%	384.37µs	359.28µs	🟢 -6.46%	🔴 110%
execute/ recursive_scan	214.31µs	214.10µs	⚪ -0.16%	483.34µs	465.39µs	🟢 -3.61%	🔴 117%
execute/ recursive_trap	16.87µs	16.92µs	⚪ 0.30%	36.57µs	35.95µs	⚪ -1.65%	🔴 112%
execute/ regex_redux	661.70µs	664.07µs	⚪ 0.61%	1.60ms	1.61ms	⚪ 0.98%	🔴 143%
execute/ rev_complement	592.70µs	611.12µs	🔴 3.11%	1.56ms	1.56ms	⚪ 0.15%	🔴 155%
execute/ tiny_keccak	460.60µs	453.85µs	⚪ -1.45%	1.38ms	1.40ms	🔴 1.48%	🔴 208%
execute/ trunc_f2i	1.08ms	1.08ms	⚪ -0.05%	2.66ms	2.66ms	⚪ -0.12%	🔴 146%
instantiate/ wasm_kernel	68.26µs	71.68µs	🔴 4.36%	91.84µs	92.71µs	⚪ 0.86%	🟢 29%
translate/ wasm_kernel	4.22ms	4.16ms	⚪ -1.11%	7.75ms	7.74ms	⚪ -0.02%	🟡 86%

Link to pipeline

[codecov-commenter]

Codecov Report

Merging #541 (216dc4d) into master (37f3365) will decrease coverage by 0.05%.
The diff coverage is 60.00%.

❗ Current head 216dc4d differs from pull request most recent head f54e364. Consider uploading reports for the commit f54e364 to get more accurate results

@@            Coverage Diff             @@
##           master     #541      +/-   ##
==========================================
- Coverage   79.79%   79.73%   -0.06%     
==========================================
  Files          75       75              
  Lines        6309     6303       -6     
==========================================
- Hits         5034     5026       -8     
- Misses       1275     1277       +2     

Impacted Files	Coverage Δ
crates/core/src/value.rs	63.04% <50.00%> (-0.20%)	⬇️
crates/wasmi/src/engine/executor.rs	98.10% <100.00%> (-0.03%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[yjhmelody]

What is the advantage of having ExtendInto compared to a simple From implementation?

Maybe From/Into is too loosely constraint for these types?
I only add the wasm supported type for reducing code.

I think that these trait implementations are only for one-to-one correspondence with wasm instructions, so I do so reasonably. Just like impl_transmute_into_self

[yjhmelody]

@Robbepop BTW, such as these impls are not used, since wasmi do not directly use f32/f64.

impl_extend_into!(i64, f64);
impl_extend_into!(u64, f64);
impl_extend_into!(f32, f64);

[Robbepop]

What is the advantage of having ExtendInto compared to a simple From implementation?

Maybe From/Into is too loosely constraint for these types? I only add the wasm supported type for reducing code.

I think that these trait implementations are only for one-to-one correspondence with wasm instructions, so I do so reasonably. Just like impl_transmute_into_self

Yeah I just saw that. Was looking at this PR from mobile and didn't get the code on the small format.

[Robbepop]

@Robbepop BTW, such as these impls are not used, since wasmi do not directly use f32/f64.

impl_extend_into!(i64, f64);
impl_extend_into!(u64, f64);
impl_extend_into!(f32, f64);

I think it makes sense to remove those impls. Generally there never was a clear design behind when to use f32/f64 and their F32/F64 counterparts in wasmi but I think it would make sense to just always use F32/F64 everywhere.

[Robbepop]

Renamed the PR since this does not implement any new feature but acts more like a refactoring of code.

[Robbepop]

LGTM

[Robbepop]

I think this kind of generalization of load/store operations is a step forward.