The handling of the returned attribute in D75815 did miss the case
where the argument is (bit)casted to a different type. This is
explicitly allowed by the language reference and exposed by the
Attributor.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4662 | Why only pointers?
|
LG
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4660 | I can't imagine it matters, but these should be swapped around. |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4660 | Shouldn't this be an assertion rather than an if check? |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4660 | Is there a verifier check for that? |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4660 | @nikic has a point. To fix the issue we just need the CreateBitOrPointerCast, anything that is not valid is an error in the IR. I think I'll update with an assertion. |
llvm/test/Transforms/InstCombine/call-returned.ll | ||
---|---|---|
58 | I am wondering if these all cases can be “reversed” to exploit tail call optimization. |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
4660 |
Hm, i guess it depends on how you look at it, either one can be argued to be the right one. |
I'd prefer for the current patch to proceed as-is first, and for things to be refactored later.
<jdoerfert> LebedevRI: are u OK with the assertion instead of the conditional? <LebedevRI> if we want to make that an assertion, we should do it in verifier <LebedevRI> and avoid assertion there at all <LebedevRI> (there == in the patch at hand) <LebedevRI> but both the assertion and verifier may find things, so you might want to proceed with the current patch first and refactor later <jdoerfert> can u add that comment there please. I'll do that then
I can't imagine it matters, but these should be swapped around.