Details
- Reviewers
jdoerfert
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not quite sure what the intended semantics for inaccessiblememonly and readnone are here. If a pointer operand is converted to an integer and passed as an argument to a function call, when can that pointer be optimized out? Does that function need to have either attribute, or does it not matter that an integer argument is casted from a pointer? This patch currently assumes that the attribute must still be present on the function (since it can't be set on a non-pointer argument).
llvm/lib/Transforms/IPO/GlobalOpt.cpp | ||
---|---|---|
1834 | This is not sound. ptr2int + call can capture the pointer just fine so any use here has to be assumed capturing. That said, I would strongly recommend against looking through ptr2int if you don't have a good reason and good reasoning for soundness. I looked at your tests, it seems you really want to support ptr2int. I see two options:
| |
llvm/lib/Transforms/Utils/GlobalStatus.cpp | ||
164 | This is unrelated and not clear to me. | |
llvm/test/Transforms/GlobalOpt/localize-fnattr.ll | ||
95 | I'm curious, what value is passed to @foo5 here? An alloca? What if foo5 does something like: void foo5(int a) { assert(a == &G5); } If that can't happen, what if we pass @G5 twice? | |
llvm/test/Transforms/Mem2Reg/fnattr.ll | ||
60 | FWIW, the test case to break the current code looks like this: define i32* toptr(i32 %a) readnone nowunind { %ptr = inttoptr i32 %a, i32* ret %ptr } ; Do read from casted pointer argument define i32 @c() norecurse { %g3 = alloca i32 store i32 42, i32 *%g3 %p = ptrtoint i32* %g3 to i32 %clone = call i32* @toptr(i32 %p) store i32 1337, i32* %clone %c = load i32, i32* %g3 ret i32 %c } |
I'm not sure yet if I'll need to support ptrtoint; I haven't rebuilt my benchmarks with the parent changes to see if optimizations are being inhibited. But I am more inclined to avoid it if possible since I'll need to refactor and call the code to infer pointer capture.
llvm/test/Transforms/GlobalOpt/localize-fnattr.ll | ||
---|---|---|
95 | I don't believe this can happen, because the path from processGlobal() -> processInternalGlobal() -> isPointerValueDeadOnEntryToFunction() checks that the global has internal linkage and does not have multiple accessing functions. When the localized alloca of @G5 is passed in twice, they should compare equal. | |
llvm/test/Transforms/Mem2Reg/fnattr.ll | ||
60 | Ok, yeah, the capture check would be needed for this case. |
This is not sound. ptr2int + call can capture the pointer just fine so any use here has to be assumed capturing. That said, I would strongly recommend against looking through ptr2int if you don't have a good reason and good reasoning for soundness.
I looked at your tests, it seems you really want to support ptr2int. I see two options: