i#1942 vpbroadcast: Support vpbroadcastb/w/d/q AVX2 instructions

Commit log for first patchset:
---------------
i#1942 vpbroadcast: Support vpbroadcastb/w/d/q AVX2 instructions

Fixes #1942
---------------

[rocallahan, 2016-06-03 05:29:58]

I admit I wasn't completely sure what I was doing here. In particular I couldn't
figure out whether I should use vex_extensions or third_byte_38 for these
instructions. This code seems to decode the instructions correctly at least.

[bruening, 2016-06-12 21:00:58]

On 2016/06/03 05:29:58, rocallahan wrote:
> I admit I wasn't completely sure what I was doing here. In particular I
couldn't
> figure out whether I should use vex_extensions or third_byte_38 for these
> instructions. This code seems to decode the instructions correctly at least.

They can just live in the third_byte_38 array: vex_extensions is just adding
overhead unnecessarily in this case.  Since I'm committing it I will make that
change.  The rest looks good.  Thanks for the patch.

[bruening, 2016-06-12 21:01:06]

https://codereview.appspot.com/299230043/diff/1/core/arch/x86/decode_table.c
File core/arch/x86/decode_table.c (right):

https://codereview.appspot.com/299230043/diff/1/core/arch/x86/decode_table.c#...
core/arch/x86/decode_table.c:4542: {OP_vpbroadcastb, 0x66387818, "vpbroadcastb",
Vx, xx, Wb_dq, xx, xx, mrm|vex|reqp, x, END_LIST},
There is no reason to indirect these to the vex_ext table, as there is no
non-vex-encoded instruction to distinguish from.  The "vex" flag already
indicates that this is illegal without a vex encoding.

[rocallahan, 2016-06-12 21:13:39]

Great, thanks!