[PATCH] D18092: Swift Calling Convention: add swifterror attribute
Mehdi AMINI via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 1 13:32:33 PDT 2016
joker.eph added inline comments.
================
Comment at: docs/LangRef.rst:1077
@@ +1076,3 @@
+ specific register to replace loads and stores from a pointer to pointer
+ type.
+
----------------
rjmccall wrote:
> I would say:
>
> These constraints allow the calling convention to optimize access to swifterror
> variables by associating them with a specific register at call boundaries rather than
> placing them in memory. Since this does change the calling convention, a function
> which uses the swifterror attribute on a parameter is not ABI-compatible with one
> which does not.
LGTM.
Thanks you're much better at putting words together that I am :)
================
Comment at: docs/LangRef.rst:1082
@@ +1081,3 @@
+ that error objects do not alias with other objects, and two error objects
+ do not alias.
+
----------------
rjmccall wrote:
> I would say:
>
> These constraints also allow LLVM to assume that a swifterror argument
> does not alias any other memory visible within a function and that a swifterror
> alloca passed as an argument does not escape.
It seems to me that this address the swift-error "fake pointer", but not the error itself. Can we (Do we want) to provide guarantee on the error object as well?
http://reviews.llvm.org/D18092
More information about the llvm-commits
mailing list