aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ExecutionEngine/Orc/LibraryResolverTest.cpp
diff options
context:
space:
mode:
authorNikita Popov <npopov@redhat.com>2025-10-27 09:16:48 +0100
committerGitHub <noreply@github.com>2025-10-27 09:16:48 +0100
commitde9e18dc75c432a59e94cecd0cab42909893123a (patch)
tree28a7420780a4ce940387e88c6adea8a7cec0c0f0 /llvm/unittests/ExecutionEngine/Orc/LibraryResolverTest.cpp
parent00f5a1e30b1b2a28569c5aa24219518135d107d0 (diff)
downloadllvm-de9e18dc75c432a59e94cecd0cab42909893123a.zip
llvm-de9e18dc75c432a59e94cecd0cab42909893123a.tar.gz
llvm-de9e18dc75c432a59e94cecd0cab42909893123a.tar.bz2
[InstCombine] Handle ptrtoaddr in gep of pointer sub fold (#164818)
This extends the `ptradd x, ptrtoint(y) - ptrtoint(x)` to `y` InstCombine fold to support ptrtoaddr. In the case where x and y have the same underlying object, this is handled by InstSimplify already. If the underlying object may differ, the replacement can only be performed if provenance does not matter. For pointers with non-address bits we need to be careful here, because the pattern will return a pointer with the non-address bits of x and the address bits of y. As such, uses in ptrtoaddr are safe to replace, but uses in ptrtoint are not. Whether uses in icmp are safe to replace depends on the outcome of the pending discussion on icmp semantics (I'll adjust this in https://github.com/llvm/llvm-project/pull/163936 if/when that lands).
Diffstat (limited to 'llvm/unittests/ExecutionEngine/Orc/LibraryResolverTest.cpp')
0 files changed, 0 insertions, 0 deletions