mirror of
https://github.com/FEX-Emu/FEX.git
synced 2026-10-06 12:00:17 +02:00
Alyssa Rosenzweig
bd4464bd5e
Instruction count CI has transformed the way we work on FEX… I love the system and want to make it better. there’s one part of instruction count CI that isn’t so lovable: the problematic “optimal” flag on instructions. There are several issues with this flag, both philosophical and practical. – it is tedious to update the optimal flag when making an implementation optimal. The effect of that is discouraging people from making instructions, optimal, or encouraging people to fail to update the flag, and dilute the value of it. Either way, since we care far more about optimal implementations, then we do about updating the flag, clearly we should prioritize the implementation and not the flag. This issue was not obvious at the outset, when instruction count, CI was introduced, and still quite small. The problem magnified when we started duplicating instructions in bulk for different combinations of CPU features (flagm, AFP, etc.) that intern multiplies the manual work required to update the flags by the corresponding constant factor. if it comes down to a choice between removing this extra coverage and removing the flag, I think we all agree that removing the flag is the lesser evil. – The definition of “optimal” is fundamentally problematic. I have often improved the instruction count of an instruction that was already “optimal”. This is all kinds of silly, and calls into question whether there’s any value whatsoever in the existing classifications of the flag. Furthermore, it is often unknowable, whether an implementation really is optimal. Is it possible to implement BZHI (with flag calculations) in fewer than eight instructions? We don’t know, and it’s silly to pretend that we do. – as a consequence of the problematic definitions , there are so many errors in both directions that I don’t think there’s much value in preserving the existing classification at the expense of +progress. Being able to say “32% of instructions are translated optimally” is neat, but it really doesn’t tell us anything whatsoever when you dig a little deeper. So, as the flag is misleading at best and perhaps harmful at worst, let’s remove it and make the instruction count CI, more useful overall. let’s let the expected count and the assembly speak for themselves, and cut away the chaff. if we want a meaningless number to report to management, we can instead calculate the average blowup factor ;-) Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
124 lines
2.8 KiB
JSON
124 lines
2.8 KiB
JSON
{
|
|
"Features": {
|
|
"Bitness": 64,
|
|
"EnabledHostFeatures": [
|
|
"SVE128",
|
|
"SVE256",
|
|
"AFP"
|
|
],
|
|
"DisabledHostFeatures": []
|
|
},
|
|
"Instructions": {
|
|
"vroundss xmm0, xmm1, 00000000b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"nearest rounding",
|
|
"Map 3 0b01 0x0a 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintn s16, s16"
|
|
]
|
|
},
|
|
"vroundss xmm0, xmm1, 00000001b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"-inf rounding",
|
|
"Map 3 0b01 0x0a 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintm s16, s16"
|
|
]
|
|
},
|
|
"vroundss xmm0, xmm1, 00000010b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"+inf rounding",
|
|
"Map 3 0b01 0x0a 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintp s16, s16"
|
|
]
|
|
},
|
|
"vroundss xmm0, xmm1, 00000011b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"truncate rounding",
|
|
"Map 3 0b01 0x0a 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintz s16, s16"
|
|
]
|
|
},
|
|
"vroundss xmm0, xmm1, 00000100b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"host mode rounding",
|
|
"Map 3 0b01 0x0a 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frinti s16, s16"
|
|
]
|
|
},
|
|
"vroundsd xmm0, xmm1, 00000000b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"nearest rounding",
|
|
"Map 3 0b01 0x0b 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintn d16, d16"
|
|
]
|
|
},
|
|
"vroundsd xmm0, xmm1, 00000001b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"-inf rounding",
|
|
"Map 3 0b01 0x0b 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintm d16, d16"
|
|
]
|
|
},
|
|
"vroundsd xmm0, xmm1, 00000010b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"+inf rounding",
|
|
"Map 3 0b01 0x0b 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintp d16, d16"
|
|
]
|
|
},
|
|
"vroundsd xmm0, xmm1, 00000011b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"truncate rounding",
|
|
"Map 3 0b01 0x0b 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frintz d16, d16"
|
|
]
|
|
},
|
|
"vroundsd xmm0, xmm1, 00000100b": {
|
|
"ExpectedInstructionCount": 2,
|
|
"Comment": [
|
|
"host mode rounding",
|
|
"Map 3 0b01 0x0b 128-bit"
|
|
],
|
|
"ExpectedArm64ASM": [
|
|
"mov v16.16b, v16.16b",
|
|
"frinti d16, d16"
|
|
]
|
|
}
|
|
}
|
|
}
|