On December 13, 2018 04:07:56 Iago Toral <[email protected]> wrote:
On Thu, 2018-12-06 at 13:45 -0600, Jason Ekstrand wrote: (...)diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h index 30fa1d7ec8b..e0cdcd4ba23 100644 --- a/src/compiler/nir/nir_builder.h +++ b/src/compiler/nir/nir_builder.h @@ -963,6 +963,18 @@ nir_load_param(nir_builder *build, uint32_t param_idx) #include "nir_builder_opcodes.h" +static inline nir_ssa_def * +nir_f2b(nir_builder *build, nir_ssa_def *f) +{ + return nir_f2b32(build, f); +} + +static inline nir_ssa_def * +nir_i2b(nir_builder *build, nir_ssa_def *i) +{ + return nir_i2b32(build, i); +} +any particular reason why wanted these instead of just calling the 32- bit opcode directly from the caller?
In my 1-bit booleans series, it lets me switch most of NIR without having to manually edit every single place we do a x2b conversion.
I need to do b2f conversions in a couple of places where the destination can be 16, 32 or 64 and I think it is more convenient to have helpers that take the destination bit-size as parameter and then emit the appropriate opcode instead. What do you think?
For b2f, I totally agree. In fact, I've considered adding a small bit of codegen to nir_builder to add such a pole of helpers. One of my patch series (I don't remember which at this point) adds i2i and u2u helpers that take a bit size like you suggest.
--Jason _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
