Yes, it was I who put that rant in the commit log and it's justified. Worse, it's unreasonable to actually go through all of DAGCombiner's code and check to see if certain kinds of constants, e.g., i64, are legal during a particular phase of DAGCombiner. DAGCombiner does good work and the backends are supposed to be good citizens. CellSPU is certainly trying to be a good citizen, no matter how frustrating that becomes on certain days.<br>
<br>We need to document this knowledge somewhere:<br><br> (a) If you're going to legalize operations, you should constrain yourself to using target independent nodes insofar as feasible. Think twice before adding a new pseudo-instruction: it prevents DAGCombiner optimizations and sometimes DAGcombiner will unintentionally work around your operation legalizations in unexpected ways (i.e., transforming (fabs:f64 arg) to (bitconvert:f64 (and:i64 (bitconvert:i64 arg), 0x7fffffffffffffff)))<br>
<br>(b) If you add new pseudo-instructions (i.e., target-specific nodes in your ISelLowering source), make sure you know how to PerformDAGCombine. If there's no possible way to do PerformDAGCombine on your new pseudo-instructions, see (a).<br>
<br>(c) If at all possible, handle target-specific instruction selection, e.g., 64-bit loads or other speciality instruction selection, in your ISelDAGToDAG source. For example, CellSPU cannot lower 64-bit add, substract or multiply operations using target-independent nodes. These are custom instruction-selected using pseudo-instructions that only the instruction selector will see.<br>
<br>(d) If (a), (b) or (c) don't work, then, and only then, create a new target-dependent node and its corresponding ISD-extended pseudo instruction.<br><br><br>