On Fri, Oct 5, 2018 at 11:15 AM Sagar Ghuge <sagar.gh...@intel.com> wrote: > > avoid misinterpretation of encoded immediate values in instruction and > disassembled output. > > Signed-off-by: Sagar Ghuge <sagar.gh...@intel.com> > --- > While encoding the immediate floating point values in instruction we use > values upto precision 8, but while disassembling, we print precision to > 6 places, which round up the value and gives wrong interpretation for > encoded immediate constant. Printing it upto precision 8 will help in > reassembling it again.
Let's put that in the commit message. > src/intel/compiler/brw_disasm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c > index 322f4544df..7cbbc080b3 100644 > --- a/src/intel/compiler/brw_disasm.c > +++ b/src/intel/compiler/brw_disasm.c > @@ -1293,7 +1293,7 @@ imm(FILE *file, const struct gen_device_info *devinfo, > enum brw_reg_type type, > format(file, "0x%08xV", brw_inst_imm_ud(devinfo, inst)); > break; > case BRW_REGISTER_TYPE_F: > - format(file, "%-gF", brw_inst_imm_f(devinfo, inst)); > + format(file, "%.8fF", brw_inst_imm_f(devinfo, inst)); I'm not sure 8 digits is sufficient to get an exact representation that the assembler can "round-trip". This page [1] indicates that 9 digits are necessary for binary->decimal->binary round-trips. NIR takes another approach: vec1 32 ssa_0 = load_const (0x3f800000 /* 1.000000 */) What do you think about printing the binary representation and the floating-point value? That way humans can easily read one number and the assembler can easily read the other :) Also, I think the DF case immediately after this should be handled as well. [1] https://www.exploringbinary.com/number-of-digits-required-for-round-trip-conversions/ _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev