[Mesa-dev] Possible bug in nir_algebraic?

[Ian Romanick]

I have encountered what I believe to be a bug in nir_algebraic.  Since
the rewrite to use automata, I'm not sure how to begin debugging it.
I'm looking for some suggestions... even if the suggestion is, "Fix your
patterns."

I have added a pattern like:

   (('~fadd at 32', ('fmul', ('fadd', 1.0, ('fneg', a)),
                          ('fadd', 1.0, ('fneg', a))),
                 ('fmul', ('flrp', a, 1.0, a), b)),
    ('flrp', 1.0, b, a), '!options->lower_flrp32'),

While using NIR_PRINT=1, I see this in my instruction stream:

        vec1 32 ssa_2 = load_const (0x3f800000 /* 1.000000 */)
        ...
        vec1 32 ssa_196 = intrinsic load_uniform (ssa_195) (68, 4, 160)
        vec1 32 ssa_83 = fneg ssa_196
        vec1 32 ssa_84 = fadd ssa_83, ssa_2
        vec1 32 ssa_85 = fmul ssa_84, ssa_84
        ...
        vec1 32 ssa_95 = flrp ssa_196, ssa_2, ssa_196
        vec1 32 ssa_96 = fmul ssa_78, ssa_95
        vec1 32 ssa_97 = fadd ssa_96, ssa_85

But nir_opt_algebraic does not make any progress.  It sure looks like it
should trigger with a = ssa_196 and b = ssa_78.

However, progress is made if I change the pattern to

   (('~fadd at 32', ('fmul', ('fadd', 1.0, ('fneg', a)),
                          c),
                 ('fmul', ('flrp', a, 1.0, a), b)),
    ('flrp', 1.0, b, a), '!options->lower_flrp32'),

ssa_85 is definitely ('fmul', ssa_84, ssa_84), and ssa_84 is definitely
('fadd', 1.0, ('fneg', ssa_196))... both times. :)