[llvm-commits] [llvm] r52893 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAG.h lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/Alpha/AlphaISelLowering.cpp lib/Target/CellSPU/SPUISelLowering.cpp lib/Target/Mips/MipsISelLowering.cpp lib/Target/PIC16/PIC16ISelLowering.cpp lib/Target/PowerPC/PPCISelLowering.cpp lib/Target/Sparc/SparcISelLowering.cpp lib/Target/X86/X86ISelLowering.cpp

Chris Lattner clattner at apple.com
Tue Jul 1 10:01:41 PDT 2008


On Jul 1, 2008, at 12:55 AM, Duncan Sands wrote:

> Hi Chris,
>
>>> +  /// getMergeValues - Create a MERGE_VALUES node from the given
>>> types and ops.
>>> +  /// Allowed to return something different (and simpler) if
>>> Simplify is true.
>>> +  SDOperand getMergeValues(SDVTList VTs, SDOperandPtr Ops, unsigned
>>> NumOps,
>>> +                           bool Simplify = true) {
>>> +    if (Simplify && NumOps == 1)
>>> +      return Ops[0];
>>> +    return getNode(ISD::MERGE_VALUES, VTs, Ops, NumOps);
>>> +  }
>>
>> Why require clients to pass in the VTlist?  Can it be inferred from
>> the operands?  Since 'getMergeValues' is specific to the MERGE_VALUES
>> node, it seems like a nicety to do that.
>
> the value types can be inferred from the operands.  This is the case
> for getNode too.  I assumed that the value types were passed to  
> getNode
> as a sanity check, so it seemed good to sanity check getMergeValues  
> too;
> but perhaps they are passed for efficiency reasons?

The idea was that the general ::getNode() methods should specify it  
for uniformity.  Specialized methods (like getCopyFromReg and your new  
method) which only produce a single node type can/should be optimized  
for that node type.

Does that seem reasonable?

-Chris



More information about the llvm-commits mailing list