This is an archive of the discontinued LLVM Phabricator instance.

[LegalizeTypes][RISCV] Enable expanding {S,U}INT_TO_FP for bf16 when bf16 is a legal type
AbandonedPublic

Authored by asb on Aug 9 2023, 7:35 AM.

Details

Summary

This finishes enabling all tests in bfloat-convert.ll.

Although in this particular case it should be trivial, this conservatively leaves strict conversions to future work that would introduce proper test coverage. There are substantial gaps here right now for systems where bf16 isn't a legal type - there are no STRICT_BF16_TO_FP or STRICT_FP_TO_BF16 nodes and even for half types where the appropriate node exists, the needed logic isn't yet implemented in LegalizeFloatTypes.cpp.

Diff Detail

Event Timeline

asb created this revision.Aug 9 2023, 7:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2023, 7:35 AM
asb requested review of this revision.Aug 9 2023, 7:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2023, 7:35 AM

Doesn't this have potential for double rounding? Though I don't know what to do about that.

Doesn't this have potential for double rounding? Though I don't know what to do about that.

I'm not totally sure what the 'ideal' semantics are here, though this two-stage rounding does match what is done for x86_64:

pushq	%rax
cvtsi2ss	%rdi, %xmm0
callq	__truncsfbf2@PLT
popq	%rax
retq

and of course the other RISC-V test cases that aren't impacted by this change (RV64ID and RV32ID check lines).

CC @bkramer @pengfei

Doesn't this have potential for double rounding? Though I don't know what to do about that.

Yes, this is just broken. I assume what happened here is that we did the conversions this way for half because there isn't a precision issue there (any integer that can't be exactly converted to a float would overflow a half). Then someone copied the approach for bfloat16 without actually thinking about it.

For 32-bit integers, we can abuse the fact that int->double conversion is exact. Otherwise, I think we have to explicitly round using integer math.

Agreed with @efriedma. This is a problem and I don't have any idea other than @efriedma's suggestions.

asb abandoned this revision.Sep 20 2023, 7:45 AM

Marking as abandoned due to the double-rounding problem pointed out. https://github.com/llvm/llvm-project/pull/66903 is some preparatory refactoring prior to adding in appropriate libcalls that match those present in libgcc.