[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?
Thanks,
Dan
    
    
More information about the llvm-commits
mailing list