search for: swiftcc

...s do have the ability to return small structs in multiple registers already. > > Yes, but not all of them can return more than two, which may constrain > you if you have both error and context values in a function call, in > addition to the return value. We do actually use a different swiftcc calling convention in IR. I don’t see any serious interop problems here. The “intermediary” convention is just the original basis of swiftcc on the target. >> I don’t understand what you mean here. The out-parameter is still explicit in >> LLVM IR. Nothing about this is novel, exce...

...seregparm) that inreg is designed for. But there are targets — i386, chiefly — where inreg has a defined, stable meaning precisely because regparm has a defined, stable meaning. It seems to me that an abi(“context”) attribute would be more like the latter than the former: any target that supports swiftcc would also have to assign a stable meaning for abi(“context”). John. > > That's why ARM has different standards for hard and soft float, which > cannot mix. > > cheers, > --renato

> On Mar 2, 2016, at 11:33 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 2 March 2016 at 18:48, John McCall <rjmccall at apple.com> wrote: >> The frontend will not tell the backend explicitly which parameters will be >> in registers; it will just pass a bunch of independent scalar values, and >> the backend will assign them to registers or the stack

...value should be the second operand when used by stores %33 = alloca swifterror %swift.error*, align 8 store %swift.error** %33, %swift.error*** %.reg2mem21 swifterror argument should come from an alloca or parameter %.reload25 = load volatile %swift.error**, %swift.error*** %.reg2mem21 call swiftcc void %42(%swift.opaque* noalias nocapture nonnull sret %.reload33, %swift.refcounted* swiftself %1, %swift.error** nocapture nonnull swifterror %.reload25) LLVM ERROR: Broken function found, compilation aborted! I understand the cause of the error and disabled the demoteToStack() function(invokes...

Hi, all. Swift uses a non-standard calling convention on its supported platforms. Implementing this calling convention requires support from LLVM and (to a lesser degree) Clang. If necessary, we’re willing to keep that support in “private” branches of LLVM and Clang, but we feel it would be better to introduce it in trunk, both to (1) minimize the differences between our branches and trunk and