This patch introduces tablegen class MCStatement.
Currently, an MCStatement can be either a return statement, or a switch statement.
MCStatement: MCReturnStatement MCOpcodeSwitchStatement
A MCReturnStatement expands to a return statement, and the boolean expression associated with the return statement is described by a MCInstPredicate.
An MCOpcodeSwitchStatement is a switch statement where the condition is a check on the machine opcode. It allows the definition of multiple checks, as well as a default case. More details on the grammar implemented by these two new constructs can be found in the diff for TargetInstrPredicates.td.
With this patch, method "isThreeOperandsLEA" becomes more readable (see below):
static bool isThreeOperandsLEA(const MachineInstr &MI) { switch(MI.getOpcode()) { case X86::LEA32r : case X86::LEA64r : case X86::LEA64_32r : case X86::LEA16r : return ( MI.getOperand(1).isReg() && MI.getOperand(1).getReg() != 0 && MI.getOperand(3).isReg() && MI.getOperand(3).getReg() != 0 && ( ( MI.getOperand(4).isImm() && MI.getOperand(4).getImm() != 0 ) || (MI.getOperand(4).isGlobal()) ) ); default : return false; } // end of switch-stmt }
Before it was like this:
static bool isThreeOperandsLEA(const MachineInstr &MI) { return ( ( MI.getOpcode() == X86::LEA32r || MI.getOpcode() == X86::LEA64r || MI.getOpcode() == X86::LEA64_32r || MI.getOpcode() == X86::LEA16r ) && MI.getOperand(1).isReg() && MI.getOperand(1).getReg() != 0 && MI.getOperand(3).isReg() && MI.getOperand(3).getReg() != 0 && ( ( MI.getOperand(4).isImm() && MI.getOperand(4).getImm() != 0 ) || (MI.getOperand(4).isGlobal()) ) ); }
This patch makes it easier to read the body of auto-generated TargetInstrInfo predicates.
I also plan to reuse/extend the grammar of MCStatements to enable the definition of more complex TII hooks.
For example, I'd like in future to expand this framework to better expose dependency-breaking instructions and also instructions that have an implicit (often undocumented) false dependency on the output register (I will raise a PR for this last task). Knowledge about dep-breaking instructions (and false-deps on the output registers) could then be used by tools like llvm-mca to perform a more accurate data dependency analysis. We could also expose that knowledge to machine schedulers (for example: to tweak the data dependency graph) to improve the schedule at the end of the process.
For now, this is just a first step (mostly a minor cosmetic change to polish the new predicates framework).
Please let me know what you think.
Thanks,
-Andrea
nit: Don't really need this whitespace.