[LLVMdev] possible addrspacecast problem

[Junjie Gu]

pm = addrspacecast  float addrspace(n)* %pn  to float addrspace(m)*

If addrspace n and m refers to the same memory,  then
isDereferenceablePointter(pm) is the same as isDereferenceablePointer(pn).
This would be true for OpenCL on CPU. However,  if address space n and m
are disjoint (like in some GPU),  pn in address space n would be undefined
in address space m. Once addrspacecast'ed,  it would not be able to derive
dereferenceablity from the original pointer.  My original code segment
shows it as well.

My test case tries to have isDereferenceablePointer(pn) to be true (so
created it by alloca on stack,  which is always dereferenceable).  In this
way,  isDereferenceablePointer(pn) will be true as the current llvm
implemenation assumes isDeferenceablePointer(pn) =
isDereferenceablePointer(pn).  The test case might be a not very good code,
 but it is correct.

"Have you tried making addrspacecast not isSafeToSpeculativelyExecute?"
    isSafeToSpeculativelyExecute() invokes isDeferenceablePointer() to
check if it is speculative.  So, my patch will make
isSafeTospeculativeExecute() to return false.

"but since the testcase can be predicated on the address space your
testcase looks broken"
Could you elaborate on this ?




On Mon, Mar 16, 2015 at 4:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

>  On 03/15/2015 10:43 PM, Junjie Gu wrote:
>
>   Given a pointer,  does any addrspacecast affect the pointer's
> dereferenceablity ?  For example,
>     %pm = addrspaacecast float addrspacecast(n)* %pn to float
> addrspacecast(m)*
>     %r  = load float addrspace(m)* %pm
> In another word. the question is whether the following is true ?
>     isDereferenceablePointer(pn) == isDereferenceablePointer(pm)
>
>   [Note that the function is defined as
>    Value.cpp:isDereferenceaablePointer(const Value*, ...) ]
>
>
> The reason I am asking this is that the current LLVM thinks the answer is
> yes
> (they are the same).  But for the following case, it will make
> non-speculative
> load to be moved out of its guard.  For example (assume that
> isDereferenceablePointer(p)
> is true),
>
> The following code:
>
>      %pm = addrspaacecast float* %p to float addrspacecast(m)*
>      if (p is in addrspace(m))
>         // BB_then
>         %r0 = load float,  float addrspace(m)* %pm;
>      else  // p is in default addrspace
>         // BB_else
>         %r1 = load float,  float* p;
>      %r = phi float [r0, BB_then], [r1, BB_else]
>
> will be transformed to
>
>      %pm = addrspaacecast float* %p to float addrspacecast(m)*
>      %r0 = load float addrspace(m)* %pm;
>      %r1 = load float* p;
>      %r = select i1 (p is in adrspace(m)) float %r0, float %r1
>
> which is wrong as "%r0 = load float addrspace(m)* %pm" would be illegal
> if (p is in addrspace(m)) is false.
>
> If we agree that the answer to the above question is no, then fix
> is simple (fix diff is attached). I also have a small test to show
> the problem,  simplifyCFG actually does the above transformation
> (to reproduce, use "opt -simplifycfg -S test3.ll -o tt.ll).
>
>  Any suggestions/comments ?
>
>
>  thanks
>  Junjie
>
>
>
> I think the pointer should still be dereferencable once casted, but since
> the testcase can be predicated on the address space your testcase looks
> broken. Have you tried making addrspacecast not
> isSafeToSpeculativelyExecute?
>
>
>
>
> fix.diff
>
> Index: Value.cpp
> ===================================================================
> --- Value.cpp	(revision 232165)
> +++ Value.cpp	(working copy)
> @@ -574,8 +574,8 @@
>        return isDereferenceablePointer(RelocateInst.derivedPtr(), DL, Visited);
>      }
>
> -  if (const AddrSpaceCastInst *ASC = dyn_cast<AddrSpaceCastInst>(V))
> -    return isDereferenceablePointer(ASC->getOperand(0), DL, Visited);
> +//  if (const AddrSpaceCastInst *ASC = dyn_cast<AddrSpaceCastInst>(V))
> +//    return isDereferenceablePointer(ASC->getOperand(0), DL, Visited);
>
>    // If we don't know, assume the worst.
>    return false;
>
>
>
>
>  _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/bb4ea16d/attachment.html>