Fix incorrect regmove and fill encodings for SIMD types

- `fill` attempted to use a GPR recipe, `fillSib32`, instead of its FPR equivalent, `ffillSib32` (code compiled without error but incorrect instructions were allowed, e.g. `v1 = regmove v0, %rdi -> %xmm0`
- `regmove` could be encoded with a GPR recipe, `rmov`, which hid the above incorrectness; now only FPR-to-FPR regmoves are allowed using the `frmov` recipe
This commit is contained in:
Andrew Brown
2019-09-20 13:44:42 -07:00
committed by Dan Gohman
parent 9b8e7b511e
commit 2330ca7e2c

View File

@@ -1989,7 +1989,7 @@ pub(crate) fn define(
// Fill
let bound_fill = fill.bind_vector_from_lane(ty, sse_vector_size);
e.enc_32_64(bound_fill, rec_fillSib32.opcodes(vec![0x0f, 0x10]));
e.enc_32_64(bound_fill, rec_ffillSib32.opcodes(vec![0x0f, 0x10]));
let bound_regfill = regfill.bind_vector_from_lane(ty, sse_vector_size);
e.enc_32_64(bound_regfill, rec_fregfill32.opcodes(vec![0x0f, 0x10]));
let bound_fill_nop = fill_nop.bind_vector_from_lane(ty, sse_vector_size);
@@ -1997,7 +1997,6 @@ pub(crate) fn define(
// Regmove
let bound_regmove = regmove.bind_vector_from_lane(ty, sse_vector_size);
e.enc_32_64(bound_regmove.clone(), rec_rmov.opcodes(vec![0x0f, 0x28]));
e.enc_32_64(bound_regmove, rec_frmov.opcodes(vec![0x0f, 0x28]));
// Copy