[Mesa-dev] [PATCH 3/5] nir: Do opt_algebraic in reverse order.

Ian Romanick idr at freedesktop.org
Tue Feb 9 20:07:39 UTC 2016


On 02/08/2016 04:21 PM, Matt Turner wrote:
> On Mon, Feb 8, 2016 at 3:57 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 02/04/2016 05:47 PM, Matt Turner wrote:
>>> Walking the SSA definitions in order means that we consider the smallest
>>> algebraic optimizations before larger optimizations. So if a smaller
>>> rule is part of a larger rule, the smaller one will happen first,
>>> preventing the larger one from happening.
>>
>> Doesn't that just mean that our "larger pattern" space is somehow
>> incompletely?  This seems to indicate that applications could (but
>> probably don't?) open-code these patterns and we'll miss them.
> 
> I don't understand the question. Does my reply to Eduardo perhaps
> answer your question?

No.  I understood what he was asking about.  Let me provide a somewhat
contrived example.  Say we had only the following set of algebraic
optimizations:

   (('fadd', ('fmul', a, b), c), ('ffma', a, b, c)),
   # Replace c*b - c*a + a with flrp
   (('fsub', ('fmul', a, b), ('fadd', ('fmul', c, a), a)),
    ('flrp', a, b, c)),

Without your patch, the first optimization would occur, and the second
would never happen.  With your patch, the larger tree is examined first,
so the second optimization patter matches.

However, an application could still open code (a*b)-fma(c, a, a), and
we'll miss it with or without your patch.  The patch prevents the
optimizer from fooling itself, but the application can still fool it.
Are we better off adding more patterns so that the application can't
fool it too?


More information about the mesa-dev mailing list