This is an archive of the discontinued LLVM Phabricator instance.

CallBase: fix getFnAttr so it also checks the function
ClosedPublic

Authored by durin42 on Mar 31 2022, 7:46 AM.

Details

Summary

Prior to this change, CallBase::hasFnAttr checked the called function to
see if it had an attribute if it wasn't set on the CallBase, but
getFnAttr didn't do the same delegation, which led to very confusing
behavior. This patch fixes the issue by making CallBase::getFnAttr also
check the function under the same circumstances.

Test changes look (to me) like they're cleaning up redundant attributes
which no longer get specified both on the callee and call. We also clean
up the one ad-hoc implementation of this getter over in InlineCost.cpp.

Diff Detail

Event Timeline

durin42 created this revision.Mar 31 2022, 7:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2022, 7:46 AM
Herald added a subscriber: dexonsmith. · View Herald Transcript
durin42 requested review of this revision.Mar 31 2022, 7:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2022, 7:46 AM

This discrepancy in behavior seems to have arisen because getFnAttr was only added recently in 7557d6c896d3418216e82c0d0cf3b0708f2145bb by @aeubanks; I suspect it was an oversight not to have it match the longstanding behavior of hasFnAttr.

Looking at the call-sites, I see that llvm/lib/Analysis/InlineCost.cpp defines its own (local) getFnAttr function with this behavior, which can now be removed in favor of the common impl.

llvm/include/llvm/IR/InstrTypes.h
2310

Probably best to put this fn next to hasFnAttrOnCalledFunction in the cc file?

nikic added a reviewer: nikic.Mar 31 2022, 8:37 AM
nikic added a subscriber: nikic.
nikic added inline comments.
llvm/include/llvm/IR/InstrTypes.h
1617–1621

yes, exactly what jyknight said

durin42 updated this revision to Diff 419569.Mar 31 2022, 2:36 PM
durin42 edited the summary of this revision. (Show Details)
durin42 marked an inline comment as done.
durin42 marked an inline comment as done.Mar 31 2022, 2:37 PM
durin42 added inline comments.
llvm/include/llvm/IR/InstrTypes.h
2310

But it's a template, so it has to be in the header, right?

nikic added inline comments.Apr 1 2022, 3:35 AM
llvm/include/llvm/IR/InstrTypes.h
1625–1628

Same here, this should use getFnAttr() + isValid().

2310

You can either make it a non-template (like the functions above), or you can add an explicit template instantiation in the source file, like so:

template Attribute getFnAttrOnCalledFunction(Attribute::AttrKind Kind) const;
template Attribute getFnAttrOnCalledFunction(StringRef Kind) const;
llvm/test/Transforms/OpenMP/remove_globalization.ll
35

Hm, why do these test changes happen?

durin42 updated this revision to Diff 419788.Apr 1 2022, 9:44 AM
durin42 marked 3 inline comments as done.
durin42 added inline comments.Apr 1 2022, 9:45 AM
llvm/include/llvm/IR/InstrTypes.h
2310

I _think_ I've done what you wanted. If there's a way to get the implementation in the .cpp and the template instantiations in the .h I'm not aware of the trick and need a hand.

llvm/test/Transforms/OpenMP/remove_globalization.ll
35

Because the attribute on the call was redundant (it's already on the definition). As far as I can tell the defect in getFnAttr() was hiding the attribute because of how llvm/lib/IR/Assumptions.cpp implements llvm::hasAssumption. I didn't spot the exact logic that adds this attribute to the call, but it seems clearly redundant to me in the IR on inspection.

Same goes for the other test file.

durin42 updated this revision to Diff 419803.Apr 1 2022, 10:45 AM
nikic accepted this revision.Apr 2 2022, 1:12 AM

LG

llvm/include/llvm/IR/InstrTypes.h
28

This include shouldn't be needed?

This revision is now accepted and ready to land.Apr 2 2022, 1:12 AM
This revision was landed with ongoing or failed builds.Apr 3 2022, 8:19 PM
This revision was automatically updated to reflect the committed changes.