ScalarEvolution parses ptrtoint as ptrtoaddr losing provenance

IR & Optimizations
1

Hello,

We have encountered a bug in our downstream compiler which uses ScalarEvolutionExpander to generate LLVM IR from SCEVs. Recently, the community completely replaced SCEVPtrToIntExpr type with SCEVPtrToAddrExpr type but ScalarEvolution still supports ptrtoint instructions by parsing them as ptrtoaddr. This can result in loss of provenance when someone decides to generate code back using SCEVs. For example, consider this IR-

declare void @use_addr(i64)

define void @test_ptrtoint(ptr %q) {
entry:
%alloca = alloca [2 x i32]
%gep0 = getelementptr inbounds [2 x i32], ptr %alloca, i64 0, i64 1
%addr = ptrtoint ptr %gep0 to i64
store i32 0, ptr %gep0
store i64 %addr, ptr %q, align 8
call void @use_addr(i64 %addr);
ret void
}

%addr is parsed like this by ScalarEvolution-

%addr = ptrtoint ptr %gep0 to i64
→ (4 + (ptrtoaddr ptr %alloca to i64))

If we replaced the original %addr by the IR generated by the corresponding SCEV, we would replace ptrtoint by ptrtoaddr. Then a pass like DSE can remove the store to %gep0 as its provenance is not captured. This is essentially what we see downstream.

Is this a known issue?

2

Yeah, SCEV has a bit of a hack to treat some ptrtoint as ptrtoaddr for transition purposes. I think we should drop it if it actively causes issues, esp. as clang how emits ptrtoaddr directly in key places.

I submitted [SCEV] Do not represent ptrtoint as ptrtoaddr by nikic · Pull Request #219156 · llvm/llvm-project · GitHub to stop treating ptrtoint as ptrtoaddr.

1 Like
3

@nikic Thanks for the quick follow-up! I really appreciate it.

1 Like