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

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 1 14:05:37 PDT 2016


joker.eph accepted this revision.
joker.eph added a reviewer: joker.eph.
joker.eph added a comment.
This revision is now accepted and ready to land.

Manman: LGTM provided you add John's suggestions (no need to go through a new round of pre-commit review IMO).


================
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:
> joker.eph wrote:
> > 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?
> No.  To the extent that it's even true that the error object doesn't alias anything, it would be better to express that with other IR tools.
LGTM :)


http://reviews.llvm.org/D18092





More information about the llvm-commits mailing list