<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 31, 2014 at 3:34 PM, Paul Berry <span dir="ltr"><<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.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 dir="ltr"><div class="im">On 22 January 2014 09:16, Connor Abbott <span dir="ltr"><<a href="mailto:cwabbott0@gmail.com" target="_blank">cwabbott0@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">

<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">This series enables GLSL IR support for SSA, including passes to convert<br>

to and from SSA form. SSA is a form of the intermediate representation<br>
of a compiler in which each variable is assigned exactly once. SSA form<br>
makes many optimizations faster and easier to write, and enables other<br>
more powerful optimizations. SSA is used in GCC [1] and LLVM [2] as well<br>
as various compiler backends within Mesa itself, such as r600g-sb and<br>
Nouveau. Adding support for SSA will allow the various optimizations<br>
these backends perform to be implemented in one place, instead of<br>
making each driver reinvent the wheel (as several have already done).<br>
Additionally, all new backends would recieve these optimizations,<br>
reducing the burden of writing a compiler backend for a new driver.<br>
<br>
Even though no optimization passes are now implemented, I am putting out<br>
this series to solicit feedback on the design, to make sure I don't have<br>
to rewrite things before I go ahead and write these new passes.<br>
<br>
There are no piglit regressions on Softpipe, except for the<br>
spec/OpenGL 2.0/max-samplers test, which only passed before because the<br>
compiler happened to unroll the loop; the extra copies caused by the<br>
conversion to and from SSA stop the compiler from unrolling, meaning<br>
that the resulting GLSL IR code contains an indirect sampler index which<br>
glsl-to-tgsi can't handle.<br></blockquote><div><br></div></div><div>I had a detailed look at your patches and I really like where you're going with this.  I sent a lot of feedback in response to patches 4, 5, 7, 9, and 10; I don't think any of my feedback would require a major change to your overall plan.  Nice work!  Consider patches 1, 2, 3, 6, 8, and 11:<br>


<br>Reviewed-by: Paul Berry <<a href="mailto:stereotype441@gmail.com" target="_blank">stereotype441@gmail.com</a>><br></div></div></div></div></blockquote><div><br></div><div>Thanks Paul! I'll implement most of your changes for a v2, I only have a few things I'd like to comment on first.<br>
</div><div> </div><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 dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><div>Note, however, that probably patch 11 should be postponed until we've written something that makes use of the SSA form (i.e. the GVN-GCM algorithm you mentioned, or a direct conversion from GLSL IR to an SSA backend).</div>
</div></div></div></blockquote><div><br></div><div> Note that both the backends I wrote for the lima driver are SSA-based, so I hope to use this for that.</div><div><br></div><div>Also, a lot of the optimizations that are made possible with SSA would either be not as powerful or harder to write with a tree-based IR. For example, take GVN-GCM: part of an expression tree may be using SSA variables only, so it would be a candidate for GCM or GVM to optimize, but as long as only one part of the tree uses a non-SSA temporary, then we can't optimize the entire thing. I thought that for these sorts of situations I could implement a hack by just flattening the expression tree of anything that writes to an SSA variable, but after watching Ian's talk at FOSDEM I'm worried that this would make the current running-out-of-memory problems even worse. So, we may have to wait until "flatland" arrives before we can take full advantage of SSA. Regardless, this should help us transition to a flat IR anyways (since it makes use-def chains trivial to compute), so it may be worth it to commit this even before most of the optimizations are written (we can still do copy propagation and DCE though).</div>
<div><br></div><div>Connor</div></div></div></div>