[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:42:33 PST 2019
dexonsmith added inline comments.
================
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");
----------------
dexonsmith wrote:
> 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.`.
> Then I'd drop the unused parameter from the new one
Well, I guess it's not unused, but I'd simplify the logic so it doesn't look like things should be added.
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