<div dir="ltr">Hi, Richard, <div><br></div><div style>Your decompose vector patch works perfect on my site. Unfortunately, I still get stupid code because llvm '-dse' fails followed by 'decompose-vector' . </div>
<div style>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. </div>
<div style><br></div><div style>Sorry, I am not good at AA. In my concept, TBAA is just for C++. Do you mean that you can make use of TBAA to help DSE? </div><div style>Why TBAA is total null for my program ? basicaa is even better than -tbaa. <br>
</div><div style><br></div><div style><div>liuxin@rd58:~/testbed$ opt -tbaa -aa-eval -decompose-vectors -mem2reg -dse test.bc -debug-pass=Structure -o test.opt.bc -stats</div><div>Pass Arguments: -targetlibinfo -no-aa -tbaa -aa-eval -decompose-vectors -domtree -mem2reg -memdep -dse -preverify -verify</div>
<div>Target Library Information</div><div>No Alias Analysis (always returns 'may' alias)</div><div>Type-Based Alias Analysis</div><div> ModulePass Manager</div><div> FunctionPass Manager</div><div> Exhaustive Alias Analysis Precision Evaluator</div>
<div> Decompose vector operations into smaller pieces</div><div> Dominator Tree Construction</div><div> Promote Memory to Register</div><div> Memory Dependence Analysis</div><div> Dead Store Elimination</div>
<div> Preliminary module verification</div><div> Module Verifier</div><div> Bitcode Writer</div><div>===== Alias Analysis Evaluator Report =====</div><div> 1176 Total Alias Queries Performed</div><div> 0 no alias responses (0.0%)</div>
<div> 1176 may alias responses (100.0%)</div><div> 0 partial alias responses (0.0%)</div><div> 0 must alias responses (0.0%)</div><div> Alias Analysis Evaluator Pointer Alias Summary: 0%/100%/0%/0%</div><div> 49 Total ModRef Queries Performed</div>
<div> 0 no mod/ref responses (0.0%)</div><div> 0 mod responses (0.0%)</div><div> 0 ref responses (0.0%)</div><div> 49 mod & ref responses (100.0%)</div><div> Alias Analysis Evaluator Mod/Ref Summary: 0%/0%/0%/100%</div>
<div><br></div></div><div class="gmail_extra">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? </div>
<div class="gmail_extra">I found I can not build rDSA using the latest llvm headers. </div><div class="gmail_extra"><br></div><div class="gmail_extra">thanks,</div><div class="gmail_extra">--lx</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Oct 25, 2013 at 10:19 PM, Richard Sandiford <span dir="ltr"><<a href="mailto:rsandifo@linux.vnet.ibm.com" target="_blank">rsandifo@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">Liu Xin <<a href="mailto:navy.xliu@gmail.com">navy.xliu@gmail.com</a>> writes:<br>
> I think we are solving a same problem. I am working on shader language<br>
> too. I am not satisfied with current binaries because vector operations<br>
> are kept in llvm opt.<br>
><br>
> glsl shader language has an operation called "swizzle". It can select<br>
> sub-components of a vector. If a shader only takes components "xy" for a<br>
> vec4. it's certainly wasteful to generate 4 operations for a scalar<br>
> processor.<br>
><br>
> i think a good solution for llvm is in codegen. Many compiler has codegen<br>
> optimizer. A DSE is good enough.<br>
><br>
> Which posted patch about TBAA? you have yet another solution except<br>
> decompose-vectors?<br>
<br>
</div>Ah, no, the TBAA thing is separate really. llvmpipe generally operates<br>
on 4 rows at a time, so some functions end up with patterns like:<br>
<br>
load <16 x i8> row0 ...<br>
load <16 x i8> row1 ...<br>
load <16 x i8> row2 ...<br>
load <16 x i8> row3 ...<br>
... do stuff ...<br>
store <16 x i8> row0 ...<br>
store <16 x i8> row1 ...<br>
store <16 x i8> row2 ...<br>
store <16 x i8> row3 ...<br>
<br>
Since the row stride is variable, llvm doesn't have enough information<br>
to tell that these rows don't alias. So it has to keep the loads and<br>
stores in order. And z only has 16 general registers, so a naively-<br>
scalarised 16 x i8 operation rapidly runs out. With unmodified llvmpipe<br>
IR we get lots of spills.<br>
<br>
Since z also has x86-like register-memory operations, a few spills are<br>
usually OK. But in this case we have to load i8s and immediately<br>
spill them.<br>
<br>
So the idea was to add TBAA information to the llvmpipe IR to say that<br>
the rows don't alias. (At the moment I'm only doing that by hand on<br>
saved IR, I've not done it in llvmpipe itself yet.) Combined with<br>
-combiner-alias-analysis -combiner-global-alias-analysis, this allows<br>
the loads and stores to be reordered, which gives much better code.<br>
<br>
However, the problem at the moment is that there are other scalar loads<br>
that get rewritten by DAGCombiner and the legalisation code, and in the<br>
process lose their TBAA info. This then interferes with the optimisation<br>
above. So I wanted to make sure that the TBAA information is kept around:<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1894" target="_blank">http://llvm-reviews.chandlerc.com/D1894</a><br>
<br>
It was just that if I had a choice of only getting one of the two patches in,<br>
it'd definitely be the D1894 one. It sounds like there's more interest in<br>
the DecomposeVectors patch than I'd expected though, so I'll get back to it.<br>
<br>
Maybe as a first cut we can have a TargetTransformInfo hook to enable or<br>
disable the pass wholesale, with a command-line option to override it.<br>
<br>
Thanks to you an Renato for the feedback.<br>
<span class=""><font color="#888888"><br>
Richard<br>
<br>
</font></span></blockquote></div><br></div></div>