This attribute can be applied to a single parameter of a function or to an AllocInst.
This patch can be applied on top of the patch in reviews.llvm.org/D17866
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I was expecting a bit more tests for this, including adding the
attribute to multiple positions in the argument list, or to multiple
types, and make sure only the valid types / positions are accepted.
Something missing in this patch is a "motivation". It is not clear to me *why* we want this attribute. I'm assuming it will be used to do something smart later?
The convention allows a pointer-sized variable to be passed by reference more efficiently than simply passing a pointer to memory, as long as the variable doesn't actually need to be addressable.
OK, but to be sure I understand correctly: the "optimization" is not part of this patch right? I only see plumbing the attribute to the codegen but no use of it.
Might worth mentioning your one sentence description in the attribute description?
Also, described as you just did, I wonder if the name couldn't have been more generic than "swifterror" (not that I have a great suggestion to express what you just described though...).
Patches for the swift error attribute are separated into 3 smaller patches. This is the first patch in the series: the second patch is in review as well: http://reviews.llvm.org/D18108. I am going to upload the third patch soon. The second patch handles the target-independent portion of the optimization, and the third patch will update the targets (AArch64, X86 and ARM).
Some of the discussions can be found here:
RFC: Implementing the Swift calling convention in LLVM and Clang
https://groups.google.com/forum/#!topic/llvm-dev/epDd2w93kZ0
Correct. Actually placing the variable in a register at the point of call requires specific backend support that's been separated.
Might worth mentioning your one sentence description in the attribute description?
Seems like a reasonable request to me. Manman?
Also, described as you just did, I wonder if the name couldn't have been more generic than "swifterror" (not that I have a great suggestion to express what you just described though...).
I would be fine with the feature having a more generic name.
Thanks Mehdi for reviewing!
Manman
docs/LangRef.rst | ||
---|---|---|
1070 โ | (On Diff #51959) | 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. |
lib/IR/Verifier.cpp | ||
---|---|---|
2493 โ | (On Diff #51959) | Should this be asserting that SwiftErrorArg is an alloca? |
lib/IR/Verifier.cpp | ||
---|---|---|
1415 โ | (On Diff #51959) | You probably don't need to be this explicit; just "with pointer to pointer type" would be fine. |
1909 โ | (On Diff #51959) | For StoreInst, you should check that it's the second operand. You might also want to check that the operation isn't atomic or volatile. And you should impose a similar restriction on swifterror allocas, I think, although there you also want to permit it to be passed as a swifterror argument. (Maybe that should be allowed here, too?) |
docs/LangRef.rst | ||
---|---|---|
1067 โ | (On Diff #51959) | 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. |
1070 โ | (On Diff #51959) | 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) |
Upload new patch to address review comments.
Cheers,
Manman
docs/LangRef.rst | ||
---|---|---|
1070 โ | (On Diff #52413) | @Mehdi @John, do you have any comments on the alias part and this description in general? |
docs/LangRef.rst | ||
---|---|---|
1077 โ | (On Diff #52413) | I would say: These constraints allow the calling convention to optimize access to swifterror |
1082 โ | (On Diff #52413) | I would say: These constraints also allow LLVM to assume that a swifterror argument |
docs/LangRef.rst | ||
---|---|---|
1082 โ | (On Diff #52413) | 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. |
Manman: LGTM provided you add John's suggestions (no need to go through a new round of pre-commit review IMO).
docs/LangRef.rst | ||
---|---|---|
1082 โ | (On Diff #52413) | LGTM :) |