[LLVMdev] Is there pass to break down <4 x float> to scalars
Richard Sandiford
rsandifo at linux.vnet.ibm.com
Wed Oct 30 05:13:52 PDT 2013
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
More information about the llvm-dev
mailing list