[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
Mon Sep 22 17:08:47 PDT 2008
On Aug 29, 2008, at 8:19 AM, Duncan Sands wrote:
>> Not necessarily. The purpose of MemoryVT is to provide the type
>> when it differs from what the load or store would normally have,
>> in the case of an extending load or truncating store.
>
> This occurs exactly when the type being loaded is not legal for
> the target.
This isn't the only case where MemoryVT is used. We also use
it when folding sext/zext/trunc into loads and stores, as
an optimization on targets that can do such operations natively.
> For example, suppose in the IR you load an i8, but
> codegen on a target for which i8 is not legal (but i32 is). This
> gets turned into an extending load with MemoryVT equal to i8 and
> result type equal to i32. It seems quite similar to the situation
> of doing an atomic operation on an i8 in the IR: it would get
> legalized into an extending operation with MemoryVT equal to i8
> and (assuming the operation returned an i8 value) returning an i32.
I agree with this though.
It seems to me that MemoryVT is very appropriate for these AMOs.
And, it would be a lot cleaner than code like this:
N->getOpcode() == ISD::ATOMIC_CMP_SWAP_8 ||
N->getOpcode() == ISD::ATOMIC_SWAP_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_ADD_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_SUB_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_AND_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_OR_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_XOR_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_NAND_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MIN_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MAX_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMIN_8 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMAX_8 ||
N->getOpcode() == ISD::ATOMIC_CMP_SWAP_16 ||
N->getOpcode() == ISD::ATOMIC_SWAP_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_ADD_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_SUB_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_AND_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_OR_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_XOR_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_NAND_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MIN_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MAX_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMIN_16 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMAX_16 ||
N->getOpcode() == ISD::ATOMIC_CMP_SWAP_32 ||
N->getOpcode() == ISD::ATOMIC_SWAP_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_ADD_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_SUB_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_AND_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_OR_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_XOR_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_NAND_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MIN_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MAX_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMIN_32 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMAX_32 ||
N->getOpcode() == ISD::ATOMIC_CMP_SWAP_64 ||
N->getOpcode() == ISD::ATOMIC_SWAP_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_ADD_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_SUB_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_AND_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_OR_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_XOR_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_NAND_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MIN_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_MAX_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMIN_64 ||
N->getOpcode() == ISD::ATOMIC_LOAD_UMAX_64;
Dale, what do you think?
Dan
More information about the llvm-commits
mailing list