Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/internal/obj/x86: VPERMPD invalid encoding and too permissive argument types #25420
During fix of #24378 new issues were introduced due to shared ytab list between
If someone used negative args after CL100475, they would get invalid encoding. Their code is broken and they would've noticed that and, hopefully, reported an issue. Seems no one did that, maybe no one relied on negative arguments in their hand-coded asm or their code is not executed anymore. We could reduce "special permissive instructions" baggage by omitting this one at least until someone notices and reports that negative arguments stopped to compile (at this point, they should be happy, because if it was compiled before, it would behave in unpredictable way).
Because VEX and EVEX optabs and ytabs may soon be fully auto-generated, it's quite unfortunate to add more and more exceptions that make instruction args more permissive (Russ Cox would use "sloppy" word here, I think).
I also have a plan of leveraging immediate arg checks into deeper part of encoder to make it possible to report better errors than "invalid instruction" for immediate arg overflow or invalid signedness, so regardless of what we decide, the minimal solution is just fixing the invalid encoding problem before auto-generated tables are updated and then addressing the second issue separately, in a more clean way.
The second part of the issue is important because AVX512-enabled asm which features fully auto-generated [E]VEX optabs does not includes only unsigned immediate argument type (since there were no tests for signed consts and no issues that asked for more permissive rules).
@mvdan, I've CCed you to the CL just in case.
It's actually me who should say "apologies", since I've missed that in initial CL during review.
Better yet, no one gives apologies and we just get things fixed. :)