When parsing an instruction, the generated code (from tablegen) checks that the operand at position N matches at least one type of operand that can be found at position N.
When an instruction syntax matches, there is no additional check to verify that the parsed operands match what is required by the instruction (either that or this verification cannot differentiate between immediate and condition, I am not sure). This will result in an incorrect instruction encoding.
One way to bypass this issue is to make sure there is never an instruction with a condition and an immediate in the same operand position (the case immediate/register is already handled, and there is no possible collusion between register and condition). There is actually nothing in place to verify this property.
The only instruction that I have found with this issue is not:rci (which should be not:zrci), but I have no automatic way to verify that it is actually the only one.
When parsing an instruction, the generated code (from tablegen) checks that the operand at position N matches at least one type of operand that can be found at position N.
When an instruction syntax matches, there is no additional check to verify that the parsed operands match what is required by the instruction (either that or this verification cannot differentiate between immediate and condition, I am not sure). This will result in an incorrect instruction encoding.
One way to bypass this issue is to make sure there is never an instruction with a condition and an immediate in the same operand position (the case immediate/register is already handled, and there is no possible collusion between register and condition). There is actually nothing in place to verify this property.
The only instruction that I have found with this issue is
not:rci(which should benot:zrci), but I have no automatic way to verify that it is actually the only one.