When there is a change to IR, the comparators also need to be updated which if not done can leads to mis-compiles. The function haveSameSpecialState() in line 407 of Instruction.cpp in sync with the IR so that the comparators can call this function to compare the Instruction specific properties. The ideal thing is when IR is defined, the author should also tell how two instructions of that specific IR type can be compared. This can be done by defining a method in that subclass of IR which compares two instructions. To achieve this, a method hasSamePropertiesAs() has been added in every subclass of IR which compares the instruction specific properties of that class, like for in AllocaInst class we added the method hasSamePropertiesAs() which compares the allocated type and alignment. This can solve the following issues.
- If we add a new instruction.
In the haveSameSpecialState() in Instruction.cpp checks have been added for every known IR subclass. If the current instructions to compare don't fit into the case of any known instructions, an llvm_unreachable() call is executed. This will lead to an error when a new instruction is added but the haveSameSpecialState() function is not updated.
- If a new operand is added.
If a new operand is added to an IR instruction, there will be a need to do a lot of changes in the subclass of that IR instruction like changing the constructors. Along with these changes, an additional check need to be added in the hasSamePropertiesAs() method of that same subclass if the operand being added matters for comparison. This can be easily checked.
This minimizes the number of files to touch for a change in the IR while maintaining sync of IR with comparators.
Now that this implements a comparison rather than an equality, the name is a bit odd. Maybe compareProperties() or so?