IFORMs for load/store variants of instructions

[andreas-abel]

The 'older' instructions typically have different IFORMs for the load and store variants of the instruction (e.g., MOVSS_XMMss_XMMss_0F10 and MOVSS_XMMss_XMMss_0F11). Some newer instructions have the same IFORM for both variants (e.g., VMOVDQA32_YMMu32_MASKmskw_YMMu32_AVX512). Was this done on purpose?

[markcharney]

yeah, there are a few of these that would benefit from further disambiguation.

[markcharney]

I wrote a little script to check and there are at least 35 VMOV* AVX512 iforms that require some (suffix-based) disambiguation. I will save this for a rainy day as the iforms are used to dispatch emulation routines in Intel SDE and flows in Intel Architecture Code Analyzer (IACA).

Not all instructions have static iforms though in the text files. I need to move some code around to get all the iforms available in the interface that I'm using in my little script.

Thanks for pointing this out.

[andreas-abel]

This also applies to a several iforms that are not VMOV* iforms, e.g., VPSHAD_XMMdq_XMMdq_XMMdq.

[markcharney]

That one doesn't have a static iform so it was not considered in this round. But that example raises a larger point.

I was looking for iforms that use different "nominal opcodes". The example you point out is part of a different and far larger class of iform-aliasing that i'm not super excited to tackle. Not relevant to VPSHAD, but existing iforms do not capture the differences for the the embedded rounding forms for example. For VPSHAD, they are all the same opcode (0x9A), but the W bit gives different operand orders. Part of the reason I'm not super excited about this as it would generate large growth in the number of iforms. Maybe that would be a good thing... (I'd finally have to tackle the iform-to-string conversion such that it didn't use a static table because it would be waaaay too large for normal uses). Right now there are many users of the existing iforms so I don't really want to create that much chaos.
Possibly a build option option could generate "finer grained" iforms optionally. I need to think about it.

[andreas-abel]

The examples I was looking at were cases where different PATTERN tokens lead to the same iform. There are currently ~6300 different iforms and ~6800 different PATTERNs, so the growth wouldn't be that large.