[Mesa-dev] [PATCH RFC 00/11] glsl: add Single Static Assignment (SSA)

Connor Abbott cwabbott0 at gmail.com
Tue Feb 4 21:23:57 CET 2014


On Fri, Jan 31, 2014 at 3:34 PM, Paul Berry <stereotype441 at gmail.com> wrote:

> On 22 January 2014 09:16, Connor Abbott <cwabbott0 at gmail.com> wrote:
>
>> This series enables GLSL IR support for SSA, including passes to convert
>> to and from SSA form. SSA is a form of the intermediate representation
>> of a compiler in which each variable is assigned exactly once. SSA form
>> makes many optimizations faster and easier to write, and enables other
>> more powerful optimizations. SSA is used in GCC [1] and LLVM [2] as well
>> as various compiler backends within Mesa itself, such as r600g-sb and
>> Nouveau. Adding support for SSA will allow the various optimizations
>> these backends perform to be implemented in one place, instead of
>> making each driver reinvent the wheel (as several have already done).
>> Additionally, all new backends would recieve these optimizations,
>> reducing the burden of writing a compiler backend for a new driver.
>>
>> Even though no optimization passes are now implemented, I am putting out
>> this series to solicit feedback on the design, to make sure I don't have
>> to rewrite things before I go ahead and write these new passes.
>>
>> There are no piglit regressions on Softpipe, except for the
>> spec/OpenGL 2.0/max-samplers test, which only passed before because the
>> compiler happened to unroll the loop; the extra copies caused by the
>> conversion to and from SSA stop the compiler from unrolling, meaning
>> that the resulting GLSL IR code contains an indirect sampler index which
>> glsl-to-tgsi can't handle.
>>
>
> 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:
>
> Reviewed-by: Paul Berry <stereotype441 at gmail.com>
>

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.


>
> 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).
>

 Note that both the backends I wrote for the lima driver are SSA-based, so
I hope to use this for that.

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).

Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140204/cdea8390/attachment.html>


More information about the mesa-dev mailing list