[PATCH] D18092: Swift Calling Convention: add swifterror attribute

[Mehdi AMINI via llvm-commits]

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