[PATCH] R600/SI: Use address space in allowsUnalignedMemoryAccesses

Tom Stellard tom at stellard.net
Thu Apr 24 08:23:48 PDT 2014


On Wed, Apr 23, 2014 at 10:25:48PM +0000, Matt Arsenault wrote:
> http://reviews.llvm.org/D3477
> 
> Files:
>   lib/Target/R600/SIISelLowering.cpp
> 



> Index: lib/Target/R600/SIISelLowering.cpp
> ===================================================================
> --- lib/Target/R600/SIISelLowering.cpp
> +++ lib/Target/R600/SIISelLowering.cpp
> @@ -223,10 +223,40 @@
>  bool SITargetLowering::allowsUnalignedMemoryAccesses(EVT  VT,
>                                                       unsigned AddrSpace,
>                                                       bool *IsFast) const {
> +  if (IsFast)
> +    *IsFast = false;
> +
>    // XXX: This depends on the address space and also we may want to revist
>    // the alignment values we specify in the DataLayout.
> +
> +  // TODO: I think v3i32 should allow unaligned accesses on CI with DS_READ_B96,
> +  // which isn't a simple VT.
>    if (!VT.isSimple() || VT == MVT::Other)
>      return false;
> +
> +  // XXX - CI changes say "Support for unaligned memory accesses" but I don't
> +  // see what for specifically. The wording everywhere else seems to be the
> +  // same.
> +
> +  // 3.6.4 - Operations using pairs of VGPRs (for example: double-floats) have
> +  // no alignment restrictions.
> +  if (AddrSpace == AMDGPUAS::PRIVATE_ADDRESS) {
> +    // Using any pair of GPRs should be the same as any other pair.
> +    if (IsFast)
> +      *IsFast = true;
> +    return VT.bitsGE(MVT::i64);
> +  }
> +
> +  // XXX - The only mention I see of this in the ISA manual is for LDS direct
> +  // reads the "byte address and must be dword aligned". Is it also true for the
> +  // normal loads and stores?

I'm not sure about this, but I can look into it.

LGTM.

-Tom

> +  if (AddrSpace == AMDGPUAS::LOCAL_ADDRESS)
> +    return false;
> +
> +  // 8.1.6 - For Dword or larger reads or writes, the two LSBs of the
> +  // byte-address are ignored, thus forcing Dword alignment.
> +  if (IsFast)
> +    *IsFast = true;
>    return VT.bitsGT(MVT::i32);
>  }

> Index: lib/Target/R600/SIISelLowering.cpp
> ===================================================================
> --- lib/Target/R600/SIISelLowering.cpp
> +++ lib/Target/R600/SIISelLowering.cpp
> @@ -223,10 +223,40 @@
>  bool SITargetLowering::allowsUnalignedMemoryAccesses(EVT  VT,
>                                                       unsigned AddrSpace,
>                                                       bool *IsFast) const {
> +  if (IsFast)
> +    *IsFast = false;
> +
>    // XXX: This depends on the address space and also we may want to revist
>    // the alignment values we specify in the DataLayout.
> +
> +  // TODO: I think v3i32 should allow unaligned accesses on CI with DS_READ_B96,
> +  // which isn't a simple VT.
>    if (!VT.isSimple() || VT == MVT::Other)
>      return false;
> +
> +  // XXX - CI changes say "Support for unaligned memory accesses" but I don't
> +  // see what for specifically. The wording everywhere else seems to be the
> +  // same.
> +
> +  // 3.6.4 - Operations using pairs of VGPRs (for example: double-floats) have
> +  // no alignment restrictions.
> +  if (AddrSpace == AMDGPUAS::PRIVATE_ADDRESS) {
> +    // Using any pair of GPRs should be the same as any other pair.
> +    if (IsFast)
> +      *IsFast = true;
> +    return VT.bitsGE(MVT::i64);
> +  }
> +
> +  // XXX - The only mention I see of this in the ISA manual is for LDS direct
> +  // reads the "byte address and must be dword aligned". Is it also true for the
> +  // normal loads and stores?
> +  if (AddrSpace == AMDGPUAS::LOCAL_ADDRESS)
> +    return false;
> +
> +  // 8.1.6 - For Dword or larger reads or writes, the two LSBs of the
> +  // byte-address are ignored, thus forcing Dword alignment.
> +  if (IsFast)
> +    *IsFast = true;
>    return VT.bitsGT(MVT::i32);
>  }
>  

> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list