[LLVMdev] Any Optimization Suggestion to Get Rid of AddrSpaceCast around PHI
Changpeng Fang
changpeng.fang at gmail.com
Fri Aug 22 10:33:59 PDT 2014
On Fri, Aug 22, 2014 at 1:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:
> It's fairly simple to find all of the casts and then walk down the use
> chains, identifying whether the pointers escape, and if they don't rewrite
> all of the instructions to use the other address space. I've done this in
> an (extremely hacky) pass to allow allocas to be in an address space other
> than 0 (which I'm slowly replacing with much less hacky code).
>
But I got lost when a PHI node (as in the test case) is encountered.
> As I understand it, for your target stores in AS 4 are more expensive than
> stores in AS 3, but both can refer to the same memory?
>
> Yes. Load/store in generic address space in expansive. The casts also add
a small overhead in address computation.
Thanks;
Changpeng
> David
>
> On 21 Aug 2014, at 23:11, Changpeng Fang <cfang.llvm at gmail.com> wrote:
>
> > In the following example, for some reasons, the input pointer entering
> the loop was casted to generic pointer. How can the backend get rid of the
> > addrspacecast and use local store in the loop?
> >
> >
> > for.body.lr.ph: ; preds = %entry
> > %0 = addrspacecast i32 addrspace(3)* %in to i32 addrspace(4)*
> >
> > br label %for.body
> >
> > for.body: ; preds = %for.body, %for.body.lr.ph
> >
> > %i.03 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %for.body ]
> >
> > %ptr.02 = phi i32 addrspace(4)* [ %0, %for.body.lr.ph ], [ %add.ptr,
> %for.body ]
> >
> > store i32 %i.03, i32 addrspace(4)* %ptr.02, align 4
> >
> > %add.ptr = getelementptr inbounds i32 addrspace(4)* %ptr.02, i64 4
> >
> > %inc = add i32 %i.03, 1
> >
> > %exitcond = icmp eq i32 %inc, %numElems
> >
> > br i1 %exitcond, label %for.end, label %for.body
> >
> > for.end: ; preds = %
> >
> >
> >
> > Thanks;
> >
> > Changpeng
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/8ccb24f5/attachment.html>
More information about the llvm-dev
mailing list