[llvm-commits] [llvm] r55457 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAGNodes.h include/llvm/Target/TargetLowering.h lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp lib/Target/TargetSelectionDAG.td lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86Instr64bit.td lib/Target/X86/X86InstrInfo.td

[Dale Johannesen]

On Aug 28, 2008, at 11:14 AMPDT, Dan Gohman wrote:
> On Aug 27, 2008, at 7:44 PM, Dale Johannesen wrote:
>
>> Author: johannes
>> Date: Wed Aug 27 21:44:49 2008
>> New Revision: 55457
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=55457&view=rev
>> Log:
>> Split the ATOMIC NodeType's to include the size, e.g.
>> ATOMIC_LOAD_ADD_{8,16,32,64} instead of ATOMIC_LOAD_ADD.
>> Increased the Hardcoded Constant OpActionsCapacity to match.
>> Large but boring; no functional change.
>>
>> This is to support partial-word atomics on ppc; i8 is
>> not a valid type there, so by the time we get to lowering, the
>> ATOMIC_LOAD nodes looks the same whether the type was i8 or i32.
>> The information can be added to the AtomicSDNode, but that is the
>> largest SDNode; I don't fully understand the SDNode allocation,
>> but it is sensitive to the largest node size, so increasing
>> that must be bad.  This is the alternative.
>
>
> Hi Dale,
>
> I'd like to see if we can find an alternative to this alternative :-).
> Here's one idea:
>
> MemSDNode has a MemoryVT member. This is used for truncating
> stores and extending loads to indicate the type of the actual
> memory access. We don't have extending or truncating atomics,
> so I believe it's redundant in AtomicSDNode.
>
> Perhaps MemoryVT could be moved out of MemSDNode and into
> LSBaseSDNode? That would allow a new MVT member to be added
> to AtomicSDNode without an overall size increase.

Maybe, but MemoryVT kind of belongs in the MemSDNode, doesn't it?