[PATCH] D14305: [IR] Add a `data_ops` abstraction
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 3 19:15:48 PST 2015
reames added inline comments.
================
Comment at: include/llvm/IR/CallSite.h:172
@@ +171,3 @@
+
+ IterTy data_op_begin() const {
+ assert(getInstruction() && "Not a call or invoke instruction!");
----------------
I would just call this data_operands_X. Slightly longer, but clearer.
================
Comment at: include/llvm/IR/CallSite.h:173
@@ +172,3 @@
+ IterTy data_op_begin() const {
+ assert(getInstruction() && "Not a call or invoke instruction!");
+ return (*this)->op_begin();
----------------
Why have this assert here and no where else?
================
Comment at: include/llvm/IR/CallSite.h:268
@@ +267,3 @@
+ /// \brief Return true if the data operand (i.e. call / invoke argument or
+ /// bundle operand) at index \p i has the attribute \p A.
+ bool dataOperandHasImpliedAttr(unsigned i, Attribute::AttrKind A) const {
----------------
Stale comment?
================
Comment at: include/llvm/IR/CallSite.h:381
@@ +380,3 @@
+ /// @brief Determine whether this data operand is passed by value.
+ bool isByValArgument(unsigned OpNo) const {
+ return dataOperandHasImpliedAttr(OpNo + 1, Attribute::ByVal);
----------------
These next couple seem specific to arguments. I'd be tempted to make that explicit and use the argument version so that we get proper asserts.
================
Comment at: include/llvm/IR/CallSite.h:393
@@ +392,3 @@
+ bool isByValOrInAllocaArgument(unsigned OpNo) const {
+ return dataOperandHasImpliedAttr(OpNo + 1, Attribute::ByVal) ||
+ dataOperandHasImpliedAttr(OpNo + 1, Attribute::InAlloca);
----------------
Please just reuse the two other functions.
================
Comment at: include/llvm/IR/CallSite.h:397
@@ -370,3 +396,3 @@
- /// @brief Determine if there are is an inalloca argument. Only the last
+ /// @brief Determine if there are is an inalloca argument. Only the last call
/// argument can have the inalloca attribute.
----------------
I don't think you need the clarification here any more.
================
Comment at: include/llvm/IR/InstrTypes.h:1237
@@ -1215,6 +1236,3 @@
assert(Index < getNumOperandBundles() && "Index out of bounds!");
- auto *BOI = bundle_op_info_begin() + Index;
- auto op_begin = static_cast<const InstrTy *>(this)->op_begin();
- ArrayRef<Use> Inputs(op_begin + BOI->Begin, op_begin + BOI->End);
- return OperandBundleUse(BOI->Tag->getKey(), Inputs);
+ return operandBundleFromBundleOpInfo(bundle_op_info_begin()[Index]);
}
----------------
This looks like a possibly unrelated change?
================
Comment at: include/llvm/IR/Instructions.h:1613
@@ +1612,3 @@
+ ///
+ /// To check an attribute on the return value, set \p i to 0. To check an
+ /// attribute on the operand at index k (call argument, or bundle operand),
----------------
No! Not '0', Attribute::ReturnIndex! Don't encourage magic constants.
================
Comment at: include/llvm/IR/Instructions.h:1614
@@ +1613,3 @@
+ /// To check an attribute on the return value, set \p i to 0. To check an
+ /// attribute on the operand at index k (call argument, or bundle operand),
+ /// set \p i to k + 1.
----------------
I get what you're going for here, but the wording is really confusing. *Which* index?
For arguments, I'd just say: ZeroBasedArgNo + 1
For bundle operands, how do you even handle this? Are you essentially extending ArgNo? It's not the underlying operand number right?
================
Comment at: lib/IR/Instructions.cpp:350
@@ +349,3 @@
+
+ if (i < (getNumArgOperands() + 1))
+ return paramHasAttr(i, A);
----------------
This would also catch FunctionIndex. Intentional?
http://reviews.llvm.org/D14305
More information about the llvm-commits
mailing list