This is an archive of the discontinued LLVM Phabricator instance.

[IR] Add additional addParamAttr/removeParamAttr to AttributeList API
ClosedPublic

Authored by dneilson on May 19 2017, 6:59 AM.

Details

Summary

This is a NFC.

Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList.

Diff Detail

Repository
rL LLVM

Event Timeline

dneilson created this revision.May 19 2017, 6:59 AM
dneilson updated this revision to Diff 99607.May 19 2017, 11:37 AM

clang-formatting patch

dneilson edited the summary of this revision. (Show Details)May 19 2017, 11:46 AM
rnk edited edge metadata.May 19 2017, 2:52 PM

Thanks for working on this!

include/llvm/IR/Attributes.h
394 ↗(On Diff #99607)

I'd like to remove this overload now that it is dead within LLVM. You may need to replace it with one that takes a single Index.

lib/IR/Attributes.cpp
1023 ↗(On Diff #99607)

If we can delete this version, we don't need the comment.

javed.absar edited edge metadata.May 20 2017, 2:16 AM

Thanks a lot for this. Some small comments -

include/llvm/IR/Attributes.h
418 ↗(On Diff #99607)
  1. "returns a new set" => "returns a new list".
  1. Nitpick - it would be nice to make all such sentences same, some places we seem to start with "Returns a .. because.." other places as "Because.... returns..."
591 ↗(On Diff #99607)

Should this comment be "exists at the arg number"?

dneilson added inline comments.May 23 2017, 7:04 AM
include/llvm/IR/Attributes.h
394 ↗(On Diff #99607)

This overload appears to be used in both InstCombineCalls.cpp and CorrelatedValuePropagation.cpp (see the two changed files at the end of this patch). If I remove these overloads, then I have to rewrite those bits of code to call addAttribute() directly, instead of push_back-ing the index into a list. Seems like a reasonable change to me. Do you concur?

418 ↗(On Diff #99607)

Thanks. I agree with the nitpick; I'll try to make the comments in AttributeList more uniform.

591 ↗(On Diff #99607)

Probably, yeah. I'm fairly new to LLVM's codebase. Are args typically referred to by "argument number" or "argument index" ?

rnk added inline comments.May 23 2017, 10:22 AM
include/llvm/IR/Attributes.h
394 ↗(On Diff #99607)

I'm suggesting that you keep addParamAttributes(LLVMContext&, ArrayRef<unsigned>, Attribute A) but delete addAttribute(LLVMContext&, ArrayRef<unsigned>, Attribute A). Does that make sense?

Every call to addAttribute effectively leaks an AttributeListImpl. This code is attempting to carefully avoid making extra AttributeListImpl memory allocations, and I would like to keep that carefulness, even if not all passes are doing it. Especially because we can infer nonnull about so many call sites. The other attribute inference stuff doesn't fire nearly as often.

dneilson added inline comments.May 23 2017, 10:46 AM
include/llvm/IR/Attributes.h
394 ↗(On Diff #99607)

Ah, yes. That makes far more sense. It also gets rid of the code clone. So, it's win-win.

dneilson updated this revision to Diff 99961.May 23 2017, 11:45 AM

Addressing comments:

  • Removed the addAttribute(Ctx, Indices, Attribute) method from AttributeList, and replaces with one that operates on a single Index instead of a list.
  • Cleaned up the wording on all of the add/remove attribute comments referring to return values being immutable
dneilson marked 3 inline comments as done.May 23 2017, 11:46 AM
rnk added inline comments.May 23 2017, 1:07 PM
include/llvm/IR/Attributes.h
414 ↗(On Diff #99961)

Try to keep the triple-slash doxygen comments.

include/llvm/IR/Function.h
367 ↗(On Diff #99961)

I think saying "AttributeList ArgNo" is misleading. There is no special AttributeList argument numbering scheme, just the obvious LLVM function prototype argument number.

dneilson updated this revision to Diff 100081.May 24 2017, 7:14 AM

rnk comments + rebase

dneilson marked 2 inline comments as done.May 24 2017, 7:14 AM

ping -- To the reviewers: is this good-to-go as-is? If so, can someone please approve and push upstream (I do not have commit access).

This revision was automatically updated to reflect the committed changes.