This repository was archived by the owner on Feb 5, 2019. It is now read-only.
[X86] Fix Windows i1 zeroext conventions to use i8 instead of i32
#119
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: Re-lands r328386 and r328443, reverting r328482. Incorporates fixes from @mstorsjo in D44876 (thanks!) so that small parameters in i8 and i16 do not end up in the SysV register parameters (EDI, ESI, etc). I added tests for how we receive small parameters, since that is the important part. It's always safe to store more bytes than will be read, but the assumptions you make when loading them are what really matter. I also tested this by self-hosting clang and it passed tests on win64. Reviewers: mstorsjo, hans Subscribers: hiraditya, mstorsjo, llvm-commits Differential Revision: https://reviews.llvm.org/D44900 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328570 91177308-0d34-0410-b5e6-96231b3b80d8
|
Note that it would be desirable to backport this to 1.28. |
|
Cc @alexcrichton, not sure if you get pinged otherwise |
glandium
added a commit
to glandium/rust
that referenced
this pull request
Jun 29, 2018
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Jun 29, 2018
Update LLVM to 1c817c7a0c828b8fc8e8e462afbe5db41c7052d1 rust-lang/llvm#118 rust-lang/llvm#119
glandium
added a commit
to glandium/rust
that referenced
this pull request
Jun 29, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On Windows, the call convention for e.g. bools on x86 is to pass them as 8-bit values, which, when using registers, means using the narrowed registers (as in cl instead of ecx/rcx), so callers may just set the lower bits when passing a bool. But a rust function that receives a bool uses the entire 32/64-bits register, and may get stale bits in the non-flushed high bits, changing the meaning of the boolean value.
This probably doesn't affect rust to rust calls because llvm emits code that resets the upper bits, but it does affect ffi calls to rust, such that building Firefox with rustc > 1.24 breaks WebRender on Windows (somehow, only on debug builds). See https://bugzilla.mozilla.org/show_bug.cgi?id=1471497#c7. Who knows what else this subtly breaks.
This is a backport of llvm-mirror/llvm@ff1d4d2 .
The change to existing tests were to parts that don't exist in llvm 6.0, except for h-registers-0.ll, which is somehow unmodified (actually, it's more surprising that it needed a change on trunk).
I built llvm locally and ran all tests, with only a failure in
TargetLibraryInfoTest.ValidProtorelated to the__rust_*allocfunctions.