[PATCH] D59112: [Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic
Duncan P. N. Exon Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 7 19:29:44 PST 2019
dexonsmith accepted this revision.
dexonsmith added a comment.
LGTM too with some nitpicks (forgot to hit "submit" earlier this afternoon).
================
Comment at: lib/IR/AutoUpgrade.cpp:793-794
NewFn = nullptr;
- bool Upgraded = UpgradeIntrinsicFunction1(F, NewFn);
+ bool Upgraded = UpgradeIntrinsicFunction1(F, NewFn) ||
+ UpgradeIntrinsicFunction2(F, NewFn);
assert(F != NewFn && "Intrinsic function upgraded to the same function");
----------------
Are we going to grow more intrinsics that don't start with `llvm.`? I feel like having `clang.` was a mistake to do, and I wonder if the logic is even worth splitting out like this.
If you still think it's worth splitting, I suggest renaming `UpgradeIntrinsicFunction1` while you're in there to something meaningful (maybe in an NFC commit ahead of time), like `upgradeLLVMIntrinsicFunction`. Then I'd drop the unused parameter from the new one, and call it `upgradeClangARCIntrinsicFunction()`. This might avoid encouraging new intrinsic names that don't start with `llvm.`.
================
Comment at: lib/IR/AutoUpgrade.cpp:1585
+ // Handle clang.arc.use.
+ if (Name == "clang.arc.use") {
----------------
I think this deserves a comment for why this is correct or reasonable. Maybe something like: "clang.arc.use is an old name for llvm.arc.clang.arc.use, but we might as well drop it entirely because the optimizer now only recognizes intrinsics for ARC runtime calls."
================
Comment at: test/Bitcode/upgrade-clang-arc-use.ll:3
+
+; RUN: llvm-dis %s.bc -o - | FileCheck %s
+
----------------
Can you document what released version of LLVM was used to generate this bitcode file?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59112/new/
https://reviews.llvm.org/D59112
More information about the llvm-commits
mailing list