[LLVMdev] Is there pass to break down <4 x float> to scalars

[Liu Xin]

Richard,
Thank you. Building up a points-to algorithm is non-trivia. I will
investigate on this thread.  thank you for the suggest!
--lx



On Wed, Oct 30, 2013 at 8:13 PM, Richard Sandiford <
rsandifo at linux.vnet.ibm.com> wrote:

> Liu Xin <navy.xliu at gmail.com> writes:
> > Your decompose vector patch works perfect on my site.  Unfortunately, I
> > still get stupid code because llvm '-dse'  fails followed by
> > 'decompose-vector' .
> > I read the DSE code and it is definitely capable of eliminating unused
> > memory stores if its AA works.  I don't think basic AA works for me. I
> > found my program have complex memory accesses, such as bi-dimentional
> > arrays.
> >
> > Sorry, I am not good at AA. In my concept, TBAA is just for C++.
>
> Well, as I understand it, what's called TBAA in llvm is mostly an alias
> set hierarchy.  You can use the same infrastructure for any situation in
> which you know that two accesses can't overlap, even if that doesn't
> really map to "type"s in the language sense.  So it's more than just C++
> (or other languages, like LangRef.rst says).
>
> In my case, I'm using TBAA for IR generated by llvmpipe.  The information
> I'm adding isn't really related to the C types in llvmpipe (or gallium/mesa
> generally).  It just says that two accesses can't overlap because they
> refer to different arrays, or different rows/slices of the same array.
>
> > Do you mean that you can make use of TBAA to help DSE?
>
> The main reason I wanted TBAA is to help scheduling.  None of the
> accesses are dead, but I want to able to interleave them to reduce
> register pressure.
>
> > Why TBAA is total null for my program ? basicaa is even better than
> -tbaa.
> >
> > liuxin at rd58:~/testbed$ opt  -tbaa -aa-eval -decompose-vectors -mem2reg
> -dse
> > test.bc -debug-pass=Structure -o test.opt.bc  -stats
> > Pass Arguments:  -targetlibinfo -no-aa -tbaa -aa-eval -decompose-vectors
> > -domtree -mem2reg -memdep -dse -preverify -verify
> > Target Library Information
> > No Alias Analysis (always returns 'may' alias)
> > Type-Based Alias Analysis
> >   ModulePass Manager
> >     FunctionPass Manager
> >       Exhaustive Alias Analysis Precision Evaluator
> >       Decompose vector operations into smaller pieces
> >       Dominator Tree Construction
> >       Promote Memory to Register
> >       Memory Dependence Analysis
> >       Dead Store Elimination
> >       Preliminary module verification
> >       Module Verifier
> >     Bitcode Writer
> > ===== Alias Analysis Evaluator Report =====
> >   1176 Total Alias Queries Performed
> >   0 no alias responses (0.0%)
> >   1176 may alias responses (100.0%)
> >   0 partial alias responses (0.0%)
> >   0 must alias responses (0.0%)
> >   Alias Analysis Evaluator Pointer Alias Summary: 0%/100%/0%/0%
> >   49 Total ModRef Queries Performed
> >   0 no mod/ref responses (0.0%)
> >   0 mod responses (0.0%)
> >   0 ref responses (0.0%)
> >   49 mod & ref responses (100.0%)
> >   Alias Analysis Evaluator Mod/Ref Summary: 0%/0%/0%/100%
> >
> > Our c/c++ compiler uses steensguaard's points-to algorithm, so I turns to
> > find -steens-aa. It seems that llvm's poolalloc implements steens-aa,
> > right? does it still maintain?
> > I found I can not build rDSA using the latest llvm headers.
>
> Sorry, I don't really know this part of llvm, so I'm not sure what to
> suggest.
> Hopefully someone else will comment.
>
> Thanks,
> Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131031/d2744162/attachment.html>