This is an archive of the discontinued LLVM Phabricator instance.

[IR] Add a `data_operand` abstraction
ClosedPublic

Authored by sanjoy on Nov 3 2015, 2:06 PM.

Details

Summary

Data operands of a call or invoke consist of the call arguments, and
the bundle operands associated with the call (or invoke)
instruction. The motivation for this change is that we'd like to be
able to query "argument attributes" like readonly and nocapture
for bundle operands naturally.

This change also provides a conservative "implementation" for these
attributes for any bundle operand, and an extension point for future
work.

Diff Detail

Repository
rL LLVM

Event Timeline

sanjoy updated this revision to Diff 39117.Nov 3 2015, 2:06 PM
sanjoy retitled this revision from to [IR] Add a "parameters" abstraction.
sanjoy updated this object.
sanjoy added reviewers: reames, chandlerc, majnemer.
sanjoy added a subscriber: llvm-commits.
reames requested changes to this revision.Nov 3 2015, 3:22 PM
reames edited edge metadata.

I strongly dislike the use of parameter to refer to anything other than the call arguments. Arguments and Parameters are so strongly associated in the literature that using them for a slightly different purpose would be actively confusing.

Having an abstraction over both makes sense, but this is definitely the wrong name.

This revision now requires changes to proceed.Nov 3 2015, 3:22 PM
sanjoy added a comment.Nov 3 2015, 3:39 PM

I strongly dislike the use of parameter to refer to anything other than the call arguments. Arguments and Parameters are so strongly associated in the literature that using them for a slightly different purpose would be actively confusing.

Having an abstraction over both makes sense, but this is definitely the wrong name.

Fair enough -- do you have a suggestion? The alternatives I can think of, input and operand, are both too generic.

sanjoy retitled this revision from [IR] Add a "parameters" abstraction to [IR] Add a `data_ops` abstraction.Nov 3 2015, 6:56 PM
sanjoy updated this object.
sanjoy edited edge metadata.
sanjoy updated this revision to Diff 39147.Nov 3 2015, 6:56 PM
sanjoy edited edge metadata.
  • rename "parameters" to "data operands"
sanjoy updated this revision to Diff 39149.Nov 3 2015, 7:00 PM
sanjoy edited edge metadata.
  • comments and whitespace fixes
reames added inline comments.Nov 3 2015, 7:15 PM
include/llvm/IR/CallSite.h
172 ↗(On Diff #39149)

I would just call this data_operands_X. Slightly longer, but clearer.

173 ↗(On Diff #39149)

Why have this assert here and no where else?

268 ↗(On Diff #39149)

Stale comment?

381 ↗(On Diff #39149)

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.

393 ↗(On Diff #39149)

Please just reuse the two other functions.

397 ↗(On Diff #39149)

I don't think you need the clarification here any more.

include/llvm/IR/InstrTypes.h
1237 ↗(On Diff #39149)

This looks like a possibly unrelated change?

include/llvm/IR/Instructions.h
1613 ↗(On Diff #39149)

No! Not '0', Attribute::ReturnIndex! Don't encourage magic constants.

1614 ↗(On Diff #39149)

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?

lib/IR/Instructions.cpp
350 ↗(On Diff #39149)

This would also catch FunctionIndex. Intentional?

sanjoy marked an inline comment as done.Nov 3 2015, 7:53 PM
sanjoy added inline comments.
include/llvm/IR/CallSite.h
173 ↗(On Diff #39149)

These iterators are basically just copied over from the arg_xx iterators. :)

I'll add the assert to each of the iterator accessors.

268 ↗(On Diff #39149)

Why stale?

lib/IR/Instructions.cpp
350 ↗(On Diff #39149)

It won't since the index is unsigned.

sanjoy retitled this revision from [IR] Add a `data_ops` abstraction to [IR] Add a `data_operand` abstraction.Nov 3 2015, 8:06 PM
sanjoy updated this revision to Diff 39161.Nov 3 2015, 8:58 PM
sanjoy marked 3 inline comments as done.
  • address review comments. Note: some of the NFC refactoring has been commited separately
sanjoy added inline comments.Nov 3 2015, 9:00 PM
include/llvm/IR/Instructions.h
1614 ↗(On Diff #39149)

I've added a clarifying comment.

Only minor code comments left. Only remaining piece is a couple of stale comments.

However, I'm somewhat questioning whether this is the right direction. See my inline comment per why.

include/llvm/IR/CallSite.h
187 ↗(On Diff #39161)

use std::distance here.

273 ↗(On Diff #39161)

Doesn't distinguish between "has an attribute" and "implies an attribute". Specifically, operand bundles don't yet have per operand attributes, but do imply attributes based on their tag type. (Based on what you've said previously.)

include/llvm/IR/InstrTypes.h
1130 ↗(On Diff #39161)

Given this, I'm somewhat questioning the need for this entire change. How horrible would it be to just make each place which tries to visit call site arguments have a check for whether the call has any bundle and then bail? This sorta feels like unnecessarily generality.

include/llvm/IR/Instructions.h
3500 ↗(On Diff #39161)

Stale comment needs to updated as above.

sanjoy added inline comments.Nov 4 2015, 11:46 AM
include/llvm/IR/InstrTypes.h
1130 ↗(On Diff #39161)

We will soon have nocapture and readonly for values in the "deopt" operand bundle here.

reames accepted this revision.Nov 4 2015, 11:48 AM
reames edited edge metadata.

LGTM w/previous minor comments applied.

include/llvm/IR/InstrTypes.h
1130 ↗(On Diff #39161)

Ah. Duh. :)

This revision is now accepted and ready to land.Nov 4 2015, 11:48 AM
This revision was automatically updated to reflect the committed changes.
sanjoy marked 3 inline comments as done.