[RFC] Print FP constant assembly in hexadecimal form instead of decimal

Project Infrastructure LLVM Dev List Archives
1

Hi:

When debugging some floating point assembly, we found it is inconvenient to read the decimal constants in assembly.

In hex form many FP numbers are immediately recognizable, their exponents are more obvious etc.
We normally use hex form in debugger or LLVM IR,
not sure what is the reason that we want to use decimal in assembly?

The form change won’t change precision or affecting rounding, I think most assembler should support hex form too?

Appreciate your feedback and comments if there is anything that we should consider before changing the default behavior.

FYI. This is a patch https://reviews.llvm.org/D73566 that show the change and affected in tree testcases.
Reviews and comments are highly appreciated, thank you!

Best,

Jinsong Ji (纪金松), PhD.

XL/LLVM on Power Compiler Development
E-mail: jji@us.ibm.com

2

This seems like a really good idea!

Jacob

3

Seems reasonable to me, but we should make sure that various assemblers out there support this.
I think it would make sense to try this out on some number of platforms before proceeding. Perhaps a few Linux distros, AIX, Windows, MacOS, FreeBSD. And of course, to make sure that LLVM’s own llvm-mc understands it :slight_smile: (but I suspect this is in the mentioned patch which I haven’t looked at yet).

4

Thank you for the feedback and suggestion.

There are more than 300 testcases with hex form in assembly test under llvm source tree.
So I think at least following major tools and platforms have supported it well.
And I have tried on the platforms that I can access, no problem found yet either.

$ grep “.long\s*0x” test -R|cut -d ‘:’ -f 1 | cut -d ‘/’ -f 3 |sort|uniq
AArch64
AMDGPU
ARM
AsmParser
COFF
Hexagon
llvm-dwarfdump
llvm-objdump
llvm-readobj
llvm-symbolizer
MachO
PowerPC
RISCV
Thumb
X86

Best,

Jinsong Ji (纪金松), PhD.

XL/LLVM on Power Compiler Development
E-mail: jji@us.ibm.com

graycol.gifNemanja Ivanovic —02/04/2020 08:52:06 AM—Seems reasonable to me, but we should make sure that various assemblers out there support this.