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

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 1 11:15:24 PDT 2016


joker.eph added inline comments.

================
Comment at: docs/LangRef.rst:1067
@@ +1066,3 @@
+``swifterror``
+    This indicates that the parameter is a pointer type. That pointer holds a
+    pointer to the error object. We can only load and store from the parameter
----------------
I'm not sure the first sentence is correct: the attribute can only apply to pointers but it does *indicate* that the parameter is a pointer.

================
Comment at: docs/LangRef.rst:1070
@@ +1069,3 @@
+    to get the pointer to the error object. This is not a valid attribute for
+    return values and can only be applied to one parameter.
+
----------------
manmanren wrote:
> Loading and storing from the parameter will be optimized to reading and writing a specific register in backends that support swifterror.
> 
> A ``swifterror`` argument must be produced by an ``alloca`` instruction tagged with the ``swifterror`` keyword. Accessing the swifterror value in the caller will be optimized as well in backends that support swifterror.
Thanks to our nice whiteboard session earlier today and the pointer to the discussion, I have a much better understanding of what is going on :)

Things that may be useful to clarify (may enable further optimization in the middle end) is the aliasing part: the pointee is always an alloca and is only reachable from this pointer (can't alias with anything else in the callee).  What about the error allocation itself (i.e. the pointee pointee)?

Also the text starts with "parameter" and does not mention the alloca.  

I don't have a better name that would be more generic and carry the desired semantic (I thought about splitting it in multiple attributes to carry the various bits, but it may be overkill).

For what I'd like to see in the description, I'd imagine something along the line of:


```
This attribute is motivated to model and optimize Swift error handling. It can be attached to either a pointer-sized alloca, or a pointer-to-pointer function parameter. At call site, the actual argument that corresponds to a `swifterror` parameter has to be a `swifterror` alloca. There is at most one `swifterror` parameter in the list of function parameter. The `swifterror` attribute is part of the ABI for the function: it is undefined behavior to call a function from another translation unit with a declaration that omit the attribute. The backend calling convention for a function with a `swifterror` parameter can be implemented as an "in-out" register. To allow this optimization, it is illegal to use a `swifterror` value other than for a direct load or store (no GEP) or as a `swifterror` argument.
A `swifferror` pointer cannot alias anything, so is the pointee. (<- FIXME)
```

(note my English can probably benefit from some wordsmith)


http://reviews.llvm.org/D18092





More information about the llvm-commits mailing list