Skip to content

[LegalizeTypes][X86] Improve ExpandIntRes_FP_TO_SINT/ExpandIntRes_FP_… #3211

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 1, 2021

Conversation

compnerd
Copy link
Member

@compnerd compnerd commented Aug 30, 2021

…TO_UINT when input is SoftPromoteHalf.

Instead of splitting off the fp16 to float conversion and generating
a libcall, we should split the operation into fp16 to float and float
to integer operations. This will allow the float to integer conversion
to go through any custom handling the target has. If the target doesn't
have custom handling then we should come back to ExpandIntRes_FP_TO_SINT/
ExpandIntRes_FP_TO_UINT automatically to create the libcall.

This avoids generating libcalls on 32-bit X86. These library functions may
not exist in 32-bit libgcc. At least for LLVM, we never generate them when
hardware floating point instructions are available.

Cherry-Picked From: 201f644

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

CC: @Bigcheese
This is a cherry-pick from an upstream differential to repair the Windows x86 builds. I think it is a bit late for the 5.5 release, but I would like to see this in main so that we can get additional soak time before the rebranch.

@hyp
Copy link

hyp commented Aug 31, 2021

Looks reasonable. But this should go into apple/stable/20210107

…TO_UINT when input is SoftPromoteHalf.

Instead of splitting off the fp16 to float conversion and generating
a libcall, we should split the operation into fp16 to float and float
to integer operations. This will allow the float to integer conversion
to go through any custom handling the target has. If the target doesn't
have custom handling then we should come back to ExpandIntRes_FP_TO_SINT/
ExpandIntRes_FP_TO_UINT automatically to create the libcall.

This avoids generating libcalls on 32-bit X86. These library functions may
not exist in 32-bit libgcc. At least for LLVM, we never generate them when
hardware floating point instructions are available.

Differential Revision: https://reviews.llvm.org/D108933

(cherry picked from commit 201f644)
@compnerd compnerd changed the base branch from swift/main to apple/stable/20210107 August 31, 2021 19:26
@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

#3215 pulls this into the stable/20210726 branch as well to ensure that we don't drop this on the rebranch.

@hyp hyp self-requested a review August 31, 2021 19:34
Copy link

@hyp hyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let's get this in.

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

compnerd commented Sep 1, 2021

********************
Failed Tests (4):
  LLVM :: tools/lto/hide-linkonce-odr.ll
  LLVM :: tools/lto/no-bitcode.s
  LLVM :: tools/lto/opt-level.ll
  LLVM :: tools/lto/print-stats.ll


Testing Time: 1657.86s
  Unsupported      : 12730
  Passed           : 61286
  Expectedly Failed:   132
  Failed           :     4

The failures seem unrelated.

@hyp hyp merged commit a4b5ad9 into swiftlang:apple/stable/20210107 Sep 1, 2021
@compnerd compnerd deleted the D108933 branch September 1, 2021 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants