[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