This is an archive of the discontinued LLVM Phabricator instance.

[Win64] Handle FP arguments more gracefully under -mno-sse
ClosedPublic

Authored by rnk on Nov 19 2019, 2:38 PM.

Details

Summary

Pass small FP values in GPRs or stack memory according the the normal
convention. This is what gcc -mno-sse does on Win64.

Event Timeline

rnk created this revision.Nov 19 2019, 2:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 19 2019, 2:38 PM
Herald added a subscriber: hiraditya. · View Herald Transcript

Is a compiler abort not preferable to generating non-ABI conforming code?

rnk added a comment.Nov 19 2019, 3:26 PM

Well, specifically for the MSVC side of things, they don't implement a -mno-sse mode:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/da46257b-4d92-402f-b320-b727341f6d30/disabling-ssesse2-code-generation-in-64bit-builds?forum=vcgeneral
So, we have to make up our own rules anway.

I suppose we might as well follow GCC, then. I see they pass in GPRs in this case. Let's do that.

Isn't this passing by memory not by X87?

I'm not opposed to supporting a soft-float ABI. But I don't think -mno-sse is a strong enough signal that the user actually understands what they're asking for, as opposed to being an accidental leftover from a 32-bit project. I'd prefer to print an error.

rnk updated this revision to Diff 230174.Nov 19 2019, 4:38 PM
  • follow GCC
rnk added a comment.Nov 19 2019, 4:40 PM

I'm not opposed to supporting a soft-float ABI. But I don't think -mno-sse is a strong enough signal that the user actually understands what they're asking for, as opposed to being an accidental leftover from a 32-bit project. I'd prefer to print an error.

Well, -mno-sse seems to be enough to get GCC to do a soft-floatish thing, so I'm really just trying to follow them here. I think what we're finding in practice is that simply implementing the functionality we didn't intend to support is actually easier than nailing down the corner cases under which we should emit an error and recovering correctly.

Isn't this passing by memory not by X87?

You're right, it was. Now it converts to i32/i64, which goes via RCX/RDX/etc then stack memory.

rnk edited the summary of this revision. (Show Details)Nov 25 2019, 1:15 PM
rnk updated this revision to Diff 230963.Nov 25 2019, 1:16 PM
  • rebase
rnk added a comment.Dec 9 2019, 4:37 PM

Any thoughts on this?

In D70465#1776252, @rnk wrote:

Any thoughts on this?

I'm ok with this approach if that's what GCC does. Anyone else disagree?

Unit tests: pass. 61176 tests passed, 0 failed and 729 were skipped.

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

aemerson accepted this revision.Jan 9 2020, 12:15 PM

No objections for a week, LGTM.

This revision is now accepted and ready to land.Jan 9 2020, 12:15 PM
rnk added a comment.Jan 13 2020, 2:55 PM

Thanks, I'll rebase it and land it today. I was out skiing last week.

This revision was automatically updated to reflect the committed changes.
llvm/test/CodeGen/X86/no-sse-x86.ll