Some background on why this approach was chosen. This was discussed on Hall's Tuesday's call.
The choice of this approach for implementation is the result of how selectcc operation actions are handled. We first look at the operation action for condition code, and then based on that we look at operation action for selectcc. If we could have looked at both together, then we could have avoided expansion of selectcc, for data types that expansion is not needed, and do a simple pattern match in tablegen. Given that this is not what we currently do, we have some fairly complicated patterns reaching to instruction selection. Since these patterns has to be distinguished from the ones that we want to handle inside the PPCIselDAGtoDAG::Select, we practically need to do the full pattern matching in C++ code.
There are other approaches (for example, not expanding selectcc for floating point condition code during Operation Legalization and then adding a custom handler for vector and int data types). The reason that this approach was not taken is this: Selectcc handling is scattered in multiple places in the code. An approach like this, has the risk of breaking existing code for other data types and their corner cases and becoming a large project.
Perhaps a short comment describing what the purpose of this struct is.