This is an archive of the discontinued LLVM Phabricator instance.

Intrinsic::getName: require a Module argument
ClosedPublic

Authored by jeroen.dobbelaere on Mar 23 2021, 4:51 AM.

Details

Summary

Ensure that we provide a Module when checking if a rename of an intrinsic is necessary.

This fixes the issue that was detected by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32288
(as mentioned by @fhahn), after committing D91250.

Note that the LLVMIntrinsicCopyOverloadedName is being deprecated in favor of LLVMIntrinsicCopyOverloadedName2.

Diff Detail

Event Timeline

jeroen.dobbelaere requested review of this revision.Mar 23 2021, 4:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 23 2021, 4:51 AM
jeroen.dobbelaere edited the summary of this revision. (Show Details)
  • rebased
  • Introduced LLVMIntrinscicCopyOverloadedName2(...), Introduced `getBaseName(...)'
fhahn added a comment.Mar 24 2021, 3:34 AM

Thanks for putting up this patch! I think it's preferable to D99066, because it ensures the Module is always available if it might be needed. It's probably also worth adding a note to the release notes?

llvm/include/llvm-c/Core.h
2550

Not sure about the name, but I think Eric's suggestion of LLVMIntrinsicCopyOverloadedNameWithModule on the list seems a bit more descriptive to me. Not sure what others think and naming is hard.

llvm/include/llvm-c/Core.h
2550

There are already 17 other deprecations in favor of a '...2' name. (ex. LLVMBuildLoad2, LLVMMDStringInContext2, ...)
Which seems to be far more than the deprecations in favor of a different name. (ex. LLVMGetUnnamedAddress instead of LLVMHasUnnamedAddr2)

For this particular case, my impression is that the '...2' name is easier to grasp and to understand what it will do. In the '...WithModule', somehow I get the feeling the the module will also be copied ?

Maybe it is better to completely deprecate the original version ?

Also I am thinking of moving the ModuleRef to the beginning. What do you think ?

jeroen.dobbelaere edited the summary of this revision. (Show Details)
  • Deprecating LLVMIntrinsicCopyOverloadedName
  • Added release note.
nagisa added a subscriber: nagisa.Mar 30 2021, 7:15 AM
echristo added inline comments.Apr 10 2021, 10:15 AM
llvm/include/llvm-c/Core.h
2550

I mostly think that the "2" names aren't particularly enlightening or helpful. I'd prefer something that doesn't give us a "3" when we need or want a new argument. WithModule is perhaps not a good naming, as Florian said it's hard. Any other thoughts? ID or ModuleRef should be first. Might want to take a look at some of the other C++ intrinsic calls to get a feel for it.

Thanks for the feedback.

llvm/include/llvm-c/Core.h
2550

I mostly think that the "2" names aren't particularly enlightening or helpful. I'd prefer something that doesn't give us a "3" when we need or want a new argument. WithModule is perhaps not a good naming, as Florian said it's hard. Any other thoughts? ID or ModuleRef should be first. Might want to take a look at some of the other C++ intrinsic calls to get a feel for it.

I already moved the ModuleRef to the front, similar as in LLVMGetIntrinsicDeclaration(Mod, ID, ..).
I also looked at the history of Core.h to get a feeling about the naming. My impression is that api updates result in a new different name when that makes the api cleaner as well. In other cases, the need to add arguments resulted in adding a 2 as suffix, and deprecating the original one. (See LLVMBuildGEP2, LLVMBuildStructGEP2, LLVMGetValueName2, ...).

Other possible alternative names:

  • LLVMIntrinsicCopyOverloadedNameSupportingUnnamedTypes: maybe too long ?
  • LLVMIntrinsicCopyOverloadedNameWithModule : the WithModule part is strange
  • LLVMIntrinsicCopyOverloadedName2 : feels most natural to me: we needed to update the signature, but the functionality is still the same.

My current preference is still LLVMIntrinsicCopyOverloadedName2, although the LLVMIntrinsicCopyOverloadedNameSupportingUnnamedTypes also sounds ok.

What do you think ?

I don't really have any opinion on the name; otherwise looks fine.

llvm/include/llvm/IR/Intrinsics.h
66–74

I'd prefer to just say "M" is mandatory, rather than "recommended"; getNameNoUnnamedTypes is still available if anyone really needs it.

jeroen.dobbelaere edited the summary of this revision. (Show Details)
  • Rebased
  • Made the M parameter for 'getName' mandatory (with an assertion check)
  • I got mixed feedback with regard to the naming. I decided to settle on 'LLVMIntrinsicCopyOverloadedName2'.
jeroen.dobbelaere marked an inline comment as done.May 28 2021, 7:11 AM
jeroen.dobbelaere added inline comments.
llvm/include/llvm/IR/Intrinsics.h
66–74

I removed the mentioning of M in the documentation and added an assertion check.

jeroen.dobbelaere marked an inline comment as done.Jun 8 2021, 8:23 AM

Ping.. I would think this one is ok to land ?

nikic accepted this revision.Jun 9 2021, 2:02 PM

LGTM

llvm/lib/IR/Function.cpp
856

proved -> provide

860–862

... would be more obvious here, I think.

864

Why do we need the Intrinsic:: prefix now? Just a style change?

This revision is now accepted and ready to land.Jun 9 2021, 2:02 PM

Rebased; Taken Nikita's comments into account.

jeroen.dobbelaere marked 3 inline comments as done.Jun 14 2021, 5:51 AM

Thanks for the review and the feedback !

llvm/lib/IR/Function.cpp
864

This now is a file local static function and we need the explicit Intrinsic:: to access the getType(...) method.

This revision was landed with ongoing or failed builds.Jun 14 2021, 5:57 AM
This revision was automatically updated to reflect the committed changes.
jeroen.dobbelaere marked an inline comment as done.