[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

Dan Gohman gohman at apple.com
Thu Aug 28 11:14:06 PDT 2008

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.

What do you think?



More information about the llvm-commits mailing list