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

[Alyssa Rosenzweig]

> 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!