varungandhi-apple abandoned this revision.
varungandhi-apple added a comment.
Closing this in favor of a Swift-side fix.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D94854/new/
https://reviews.llvm.org/D94854
rjmccall added a comment.
Clang is trying to avoid using non-byte-multiple integer types for memory
accesses in LLVM IR, whereas Swift isn't. If you take your test case and make
the field non-atomic, you'll see that: Clang is accessing the field as an `i8`
and Swift is accessing it as an
varungandhi-apple added a comment.
> The way you'd test it on the Clang side would be to just write a test case
> that passes such an aggregate and tests that it's passed as an `i8`.
Ah, I just noticed an attribute `__attribute__((swiftcall))` that is used in
some test cases, I can add a test
rjmccall added a comment.
Hmm. The way you'd test it on the Clang side would be to just write a test
case that passes such an aggregate and tests that it's passed as an `i8`. But
I'm not sure it's at all unreasonable to pass this as an `i1` rather than an
`i8`; seems like something that
varungandhi-apple added a comment.
I don't know how to test this on the LLVM-side (is there a way to do it?).
Here's the Swift side test which trips over right now (but is fixed with this
patch) by attempting a zext from an i8 to an i1 in Swift's
`NativeConventionSchema::mapIntoNative`.
+++
varungandhi-apple created this revision.
varungandhi-apple added reviewers: aschwaighofer, rjmccall.
Herald added a subscriber: jfb.
varungandhi-apple requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
Fixes rdar://72999296.
Repository:
