[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

[Mon Ping Wang]

Hi,

On the PPC, what does a normal write to i8 look like? Is it  
represented as LOAD to an i8 MemoryVT?
Does it make sense when doing an ATOMIC_LOAD_ADD_8 to be  
ATOMIC_LOAD_ADD to a MemoryVT of i8 or is that senseless?

If the MemoryVT is meant only to be used the LOAD/STORES, it seems  
natural to move it down to LSBaseSDNode.  I moved it into MemSDNode  
because I thought that any memory access should have a MemoryVT  
associated with it.

-- Mon Ping

On Aug 28, 2008, at 1:14 PM, Dale Johannesen wrote:

>
> 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?
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits