[Mesa-dev] [PATCH] nir: Implement optional b2f->iand lowering

[Matt Turner]

On Mon, Apr 30, 2018 at 7:50 PM, Alyssa Rosenzweig <alyssa at rosenzweig.io> wrote:
>> Tell me a little more about what your hardware supports.
>
> Both integers and floats are first-class; they are each natively 32-bit,
> with 16-bit versions to be supported down the line. There's support for
> int8 and float64, but I haven't seen these used with GLSL, so I don't
> know how they work.
>
> From what I can tell, booleans are NIR-style: ~0 for true, 0 for false.
> There are no opcodes for b2f or f2b; instead, bitwise ops (iand, etc)
> are used for the conversion.
>
>> Interpret the source as an integer, negate it, and convert to a float.
>
> I don't believe this can done with a move, although it may be possible
> to accomplish this with a source modifier to the dedicated i2f
> instruction. I'll need to test this at some point, although I'm not
> convinced it's any faster on this architecture.
>
>> We did both of these things in our backend when translating NIR's b2f
>> into our backend IR. Why is it better for you to do that in NIR?
>
> Hmm, that's a good point. I'm not too familiar with i965's architecture,
> but at the moment, my compiler uses only a thin backend IR. That is, its
> "IR" is essentially unpacked hardware instructions, with placeholders
> instead of registers, and metadata. Given that the ISA is a good match
> for NIR, normally this simplifies the backend tremendously, as the only
> optimisation passes I need to implement are highly specialised to the
> hardware. By contrast, I would not want to implement constant folding,
> for instance, on the backend IR.
>
> I was hoping that NIR, by design, would eliminate this code duplication
> between backends. Accordingly, I try to keep code in NIR as late as
> possible, reusing standard lowering and optimisation passes.
>
> Theoretically, a patch like this would enable the lowered iand (or type
> conversion) to benefit from further NIR optimisations and allow code to
> be shared with other backends, but I'm admittedly grasping for straws
> here.
>
> The backend design is still early, and I haven't figured out what the
> ideal split of responsibilities between common code and the backend
> should be. I'm open to further input -- if major changes are needed,
> it's better for that to happen now than when I send the patches in for
> the compiler itself!

That all sounds good. Those are exactly the things we wanted when
creating NIR, so it's nice to hear :)

The only concern I have is that you'll be losing out on a number of
optimizations on b2f if you lower it to iand in the normal algebraic
optimization pass. We have a section of nir_opt_algebraic.py that runs
optimizations "late" (function is called nir_opt_algebraic_late() in
C):

# This section contains "late" optimizations that should be run after the
# regular optimizations have finished.  Optimizations should go here if
# they help code generation but do not necessarily produce code that is
# more easily optimizable.
late_optimizations = [
...
]

It might be beneficial for you to lower b2f there instead.