Re: [Mesa-dev] [PATCH] intel/compiler: Print floating point values upto precision 8
On Mon, Oct 22, 2018 at 2:14 PM Sagar Ghuge wrote: > > > > On 10/22/18 10:34 AM, Matt Turner wrote: > > On Fri, Oct 5, 2018 at 11:15 AM Sagar Ghuge wrote: > >> > >> avoid misinterpretation of encoded immediate values in instruction and > >> disassembled output. > >> > >> Signed-off-by: Sagar Ghuge > >> --- > >> 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. > > > I was also not sure about it, [1] article is nice. > > > NIR takes another approach: > > > > vec1 32 ssa_0 = load_const (0x3f80 /* 1.00 */) > > > > 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 :) > > > I think we can just print F and DF to 9 and 17 precision respectively to avoid > output alignment issue. Ken pointed out to me that this wouldn't allow us to round-trip different variations of NaN :( So I think we have to take the NIR approach. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Print floating point values upto precision 8
On 10/22/18 10:34 AM, Matt Turner wrote: > On Fri, Oct 5, 2018 at 11:15 AM Sagar Ghuge wrote: >> >> avoid misinterpretation of encoded immediate values in instruction and >> disassembled output. >> >> Signed-off-by: Sagar Ghuge >> --- >> 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. > I was also not sure about it, [1] article is nice. > NIR takes another approach: > > vec1 32 ssa_0 = load_const (0x3f80 /* 1.00 */) > > 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 :) > I think we can just print F and DF to 9 and 17 precision respectively to avoid output alignment issue. > Also, I think the DF case immediately after this should be handled as well. > Yes, I was planning to handle it when I shift to 64 bit datatypes. But I can club both in single patch. > [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
Re: [Mesa-dev] [PATCH] intel/compiler: Print floating point values upto precision 8
On Fri, Oct 5, 2018 at 11:15 AM Sagar Ghuge wrote: > > avoid misinterpretation of encoded immediate values in instruction and > disassembled output. > > Signed-off-by: Sagar Ghuge > --- > 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 (0x3f80 /* 1.00 */) 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
[Mesa-dev] [PATCH] intel/compiler: Print floating point values upto precision 8
avoid misinterpretation of encoded immediate values in instruction and disassembled output. Signed-off-by: Sagar Ghuge --- 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. 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)); break; case BRW_REGISTER_TYPE_DF: format(file, "%-gDF", brw_inst_imm_df(devinfo, inst)); -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
