[PATCH] D128900: [LoongArch] Add codegen support for converting between unsigned integer and floating-point

[WÁNG Xuěruì via Phabricator via llvm-commits]

xen0n added inline comments.


================
Comment at: llvm/test/CodeGen/LoongArch/ir-instruction/double-convert.ll:138-153
+; LA64-NEXT:    pcalau12i $a0, .LCPI7_0
+; LA64-NEXT:    addi.d $a0, $a0, .LCPI7_0
+; LA64-NEXT:    fld.d $fa1, $a0, 0
+; LA64-NEXT:    fsub.d $fa2, $fa0, $fa1
+; LA64-NEXT:    ftintrz.w.d $fa2, $fa2
+; LA64-NEXT:    movfr2gr.s $a0, $fa2
+; LA64-NEXT:    lu12i.w $a1, -524288
----------------
SixWeining wrote:
> xen0n wrote:
> > For `f64 -> u32` conversion on LA64, isn't `ftintrz.l.d` followed by `movfr2gr.s` enough for all values within `u32`'s domain? Overflow is UB both in C and LLVM IR so we can technically ignore the (very) inconsistent behavior when input overflows.
> > 
> > (BTW I noticed AArch64 has native support for the `fptoui` semantics by means of the `fcvtzu` insn. Hope LoongArch will gain similar niceties in a future revision...)
> Thanks.
> 
> Actually we have considered the approach you mentioned. But similar to the `divide-by-zero` case, we choose the same approach as gcc what did.
> 
> And I'd like to discuss with you that is there anything missed. For example,  the floating-point rounding and exception handling.  `ftintrz.l.d` may not raise exception when the value is range [UINT32_MAX + 1, INT64_MAX - 1]. Not sure whehter we need to manually raise an exception.
> 
> @xry111 Hope to see inputs from you, too.
Ah that's nice to know. Thanks for sharing the thoughts behind the current implementation decision.

As for artificial "consistency" with gcc, I think the obvious way forward is to pursue the best practice where possible, no matter which project you're working on, then make the others adopt the verified best practice. So it doesn't matter if we're working on LLVM or gcc, we simply decide on a better way then make the other project do the same.

As for the exception handling and such, my opinion is: since UB means "anything is possible", either raising exceptions or not is okay, so we may well choose the faster one, that is, simply don't care. Of course this is different from the current behavior which is saturating for out-of-range inputs, which is arguably more useful for users, but it's UB after all so I think there's definitely room for further discussion. (Ideally/academically, one would try to gather some statistics over a wide range of software corpus, then base one's argument on that; however this doesn't change the fact that such usage is invoking UB so we may not be in a position to "accommodate" for their mistakes.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128900/new/

https://reviews.llvm.org/D128900