[llvm] [NVPTX] Basic support for fp128 as a storage type (PR #136006)

[Artem Belevich via llvm-commits]

================
@@ -4,12 +4,15 @@
 target datalayout = "e-i64:64-v16:16-v32:32-n16:32:64"
 target triple = "nvptx64-nvidia-cuda"
 
-; Check that we can handle global variables of large integer type.
+; Check that we can handle global variables of large integer and fp128 type.
 
 ; (lsb) 0x0102'0304'0506...0F10 (msb)
 @gv = addrspace(1) externally_initialized global i128 21345817372864405881847059188222722561, align 16
 ; CHECK: .visible .global .align 16 .b8 gv[16] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
 
+ at gv_fp128 = addrspace(1) externally_initialized global fp128 0xL0807060504030201100F0E0D0C0B0A09, align 16
+; CHECK: .visible .global .align 16 .b8 gv_fp128[16] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
----------------
Artem-B wrote:

rant: In-memory representation of values always gives me headaches. Who'd have thought that the exponent, nominally encoded in the MSBs of the fp128 will end up in the middle of the hex representation. Bonus points for the hex representation for fp128 (but not fp32/64) becoming dependent on endianness, but only for the 64-bit parts of it.  Fun.

Oh, well, we're matching x86, and that's all that matters at the moment.
[https://godbolt.org/z/WeYPEdPzY](https://godbolt.org/z/6GfYc568r)

https://github.com/llvm/llvm-project/pull/136006