This is an archive of the discontinued LLVM Phabricator instance.

[LoongArch] Fix codegen for [su]itofp instructions
ClosedPublic

Authored by wangleiat on Oct 27 2022, 10:56 PM.

Details

Summary

This patch fixes codegen for [su]itofp instructions.

In LoongArch, a legal int-to-float conversion is done in two steps:

  1. Move the data from GPR to FPR. (FRLen >= GRLen)
  2. Conversion in FPR. (the data in FPR is treated as a signed value)

Based on the above features, when the type's BitWidth meets the
requirements, all SINT_TO_FP are legal, all UINT_TO_FP are expand
and lowered to libcall when appropriate.
The only special case is, LoongArch64 with +f,-d features. At this
point, custom processing is required for [SU]INT_TO_FP. Of course, we
can also ignore it and use libcall directly.

Diff Detail

Event Timeline

wangleiat created this revision.Oct 27 2022, 10:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 27 2022, 10:56 PM
wangleiat requested review of this revision.Oct 27 2022, 10:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 27 2022, 10:56 PM
xen0n added a comment.Oct 28 2022, 7:36 PM

Seems we're using the same methodology recently... namely trying to bootstrap a native LLVM toolchain with LLVM/Clang themselves. Because I've seen the same crash yesterday night. Thanks for catching this.

llvm/lib/Target/LoongArch/LoongArchFloat32InstrInfo.td
290

sexti32 for uint? (I might be sleepy so this might not be wrong after all.) The codegen in the touched test cases look good though, this is a bit weird.

llvm/lib/Target/LoongArch/LoongArchISelDAGToDAG.cpp
216–220

This makes me feel a bit nervous, because we conventionally use such bstrpick insns for zero extensions. The MSB immediate is tested to be strictly less than 32 so this is actually a guaranteed zero extension. Are we doing the right thing by matching the case in sexti32 too?

xen0n retitled this revision from [LoongArch] Fix codegen for [s/u]itofp instructions to [LoongArch] Fix codegen for [su]itofp instructions.Oct 28 2022, 7:38 PM
xen0n edited the summary of this revision. (Show Details)
xen0n added a comment.Oct 28 2022, 7:42 PM

Fixed formatting of commit message for you.

Note that there seems to be widespread misuse of [] and {} shorthand notations among Loongson people: they come from shell syntax, and should look like [abc], [a-c], {a,b} or {,a}, never [a/b] or {a/b}. Please keep this in mind (even the LoongArch ISA manual got this wrong, IMO it's better to tell someone to amend the manual instead of allowing the current practice last indefinitely).

Fixed formatting of commit message for you.

Note that there seems to be widespread misuse of [] and {} shorthand notations among Loongson people: they come from shell syntax, and should look like [abc], [a-c], {a,b} or {,a}, never [a/b] or {a/b}. Please keep this in mind (even the LoongArch ISA manual got this wrong, IMO it's better to tell someone to amend the manual instead of allowing the current practice last indefinitely).

Thanks!

llvm/lib/Target/LoongArch/LoongArchFloat32InstrInfo.td
290

sexti32 for uint? (I might be sleepy so this might not be wrong after all.) The codegen in the touched test cases look good though, this is a bit weird.

sexti32 means, can we treat the current node as a signed number.

llvm/lib/Target/LoongArch/LoongArchISelDAGToDAG.cpp
216–220

This makes me feel a bit nervous, because we conventionally use such bstrpick insns for zero extensions. The MSB immediate is tested to be strictly less than 32 so this is actually a guaranteed zero extension. Are we doing the right thing by matching the case in sexti32 too?

Yes, but when it only takes 31 bits, it can be considered either sign extension or zero extension.

wangleiat added inline comments.Oct 28 2022, 8:16 PM
llvm/lib/Target/LoongArch/LoongArchFloat32InstrInfo.td
290

sexti32 for uint? (I might be sleepy so this might not be wrong after all.) The codegen in the touched test cases look good though, this is a bit weird.

sexti32 means, can we treat the current node as a signed number.

In fact, this matching rule only appears when loongarch64 +f -d, but I don't want to add the corresponding hasNoBasicD() feature, and the corresponding legality judgment has been made in the lowering stage. (In theory, this constraint can be removed.)

xen0n accepted this revision.Oct 30 2022, 6:41 PM
xen0n added inline comments.
llvm/lib/Target/LoongArch/LoongArchFloat32InstrInfo.td
290

sexti32 for uint? (I might be sleepy so this might not be wrong after all.) The codegen in the touched test cases look good though, this is a bit weird.

sexti32 means, can we treat the current node as a signed number.

In fact, this matching rule only appears when loongarch64 +f -d, but I don't want to add the corresponding hasNoBasicD() feature, and the corresponding legality judgment has been made in the lowering stage. (In theory, this constraint can be removed.)

Okay, so we can put off this for a while, knowing that you're well aware of the details (better than I am)... Feel free to come back to polish it later.

llvm/lib/Target/LoongArch/LoongArchISelDAGToDAG.cpp
216–220

Fair enough. Thanks for the explanation.

This revision is now accepted and ready to land.Oct 30 2022, 6:41 PM
SixWeining accepted this revision.Nov 2 2022, 8:12 PM
This revision was automatically updated to reflect the committed changes.