Fix issue reported where intrinsic calling convention is dropped after r295253.
Details
Diff Detail
- Build Status
Buildable 4377 Build 4377: arc lint + arc unit
Event Timeline
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1922 | I think we also need to undo the name change. Setting it and then unsetting it seems a bit hacky, perhaps we could have the switch create an unnamed NewCI, and outside it do: if (NewCI != CI) { // Adjust names, and kill CI } (and remove the pre-rename)? |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1922 | Just out of curiosity, why? It is just the name of the call instruction, not the actual called function? IE it's just changing %1 = call foo We could call it ".upgraded" instead? Actually, looking closer, all the other paths erase CI completely or leave it alone, so i'm not sure why both changing the name at all. IE all the paths before it depend on !NewFn and then destroy it, even if there is no replacement. All the paths after either do nothing, erase CI completely, or are the one we are talking about. Thus it seems we could just leave the name alone and declare victory? Or am i missing something? |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1922 | I believe that if you call setName on the new instruction without changing the name of the old one, since two instructions with the same name are not allowed, the name it actually gets is name.0 or something like that (see ValueSymbolTable::createValueName). I think renaming the old instruction is a trick to prevent this from happening by avoiding the name collision. I personally do not think it is important to avoid names like name.0 when auto-upgrading; but it looks like it was important enough for someone to add that code (assuming I read the intent correctly). |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1922 | So, it looks like the code used to rename it to .old in exactly one case. In that case, it also used a dangling stringref (it's now a std::string copy, as you can see). As a fix, the renaming code got hoisted, and now everything is renamed |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1915 | How about NewCall instead of Repl? | |
2008–2009 | These should just be Repl = Builder.CreateCall(NewFn, {BC0, BC1}, Name); | |
2046 | I'm not sure if this does what used to happen before. To get the behavior intended by https://reviews.llvm.org/rL146357 I think CI->setName(Name + ".old"); needs to happen before you create a new call instruction with Name as name. Either that, or some shuffling as: if (Name not empty) { CI->setName(Name + ".old"); Repl->setName(Name); // This one should "stick" ... } |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
2008–2009 | Yeah, and the break above should be a return. | |
2046 | I don't see a way to set the name beforehand, except either unconditionally, or to do so inside the switches. Your original suggestion was: "if (NewCI != CI) { // Adjust names, and kill CI } That won't work here, as discussed :) |
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1920 | If you change this to a return then how about keeping NewCall uninitialized (instead of setting it to CI) above and removing the NewCall != CI check below? |
lgtm with two minor comments inline.
lib/IR/AutoUpgrade.cpp | ||
---|---|---|
1955 | We're doing redundant work here -- I don't think we need to pass in Name to CreateCall, since we're going to set the name explicitly anyway. Once we've removed these uses of Name, we should be able to sink the std::string Name = CI->getName(); to after the switch. | |
test/CodeGen/Generic/overloaded-intrinsic-name.ll | ||
2 | Do we really need a new RUN line here? Why not just tack on a | FileCheck %s to the already existing line? |
How about NewCall instead of Repl?