[PATCH] Removing unnecessary addrspacecasts from non-generic address spaces to the generic address space

[Jingyue Wu]

Hi Matt,

I actually think it should go to lib/Transforms/InstCombine when it gets
generalized. Also, TTI would need to expose which address space is generic
and whether such optimization would benefit at all.

Jingyue


On Mon, Mar 31, 2014 at 2:00 PM, Matt Arsenault
<Matthew.Arsenault at amd.com>wrote:

>
>   This looks like it doesn't handle vectors of pointers, although that's
> probably not very important.
>
>   I don't see anything tying this to NVPTX except the use of 0 for
> generic. Where should this go when generalized? Put it in lib/CodeGen and
> add getGenericAddressSpace() to TTI?
>
>
> ================
> Comment at: lib/Target/NVPTX/NVPTXFavorNonGenericAddrSpaces.cpp:67-72
> @@ +66,8 @@
> +
> +  Value *Src = Cast->getOperand(0);
> +  PointerType *SrcTy = cast<PointerType>(Src->getType());
> +  PointerType *DestTy = cast<PointerType>(Cast->getType());
> +  // We cannot remove the addrspacecast if the element type changes.
> +  if (SrcTy->getElementType() != DestTy->getElementType())
> +    return false;
> +
> ----------------
> If the element type changes, you can still do it, but you'll need to do
> the bitcast separately. I had a patch a while ago (
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131118/195642.html)
> to canonicalize to splitting the bitcast and addrspacecast into separate
> operations. It might be better to handle it that way than trying to figure
> it out here.
>
>
> http://llvm-reviews.chandlerc.com/D3235
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140331/1c1107ba/attachment.html>