[LLVMdev] DAGCombiner rant

[Scott Michel]

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.

We need to document this knowledge somewhere:

 (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)))

(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).

(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.

(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090125/8511b1a2/attachment.html>