[Mesa-dev] [PATCH] intel/compiler: Print floating point values upto precision 8

Matt Turner mattst88 at gmail.com
Mon Oct 22 22:21:07 UTC 2018


On Mon, Oct 22, 2018 at 2:14 PM Sagar Ghuge <sagar.ghuge at intel.com> wrote:
>
>
>
> On 10/22/18 10:34 AM, Matt Turner wrote:
> > On Fri, Oct 5, 2018 at 11:15 AM Sagar Ghuge <sagar.ghuge at intel.com> wrote:
> >>
> >> avoid misinterpretation of encoded immediate values in instruction and
> >> disassembled output.
> >>
> >> Signed-off-by: Sagar Ghuge <sagar.ghuge at 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.
> >
> I was also not sure about it, [1] article is nice.
>
> > 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 :)
> >
> 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.


More information about the mesa-dev mailing list