[llvm] [GlobalOpt] Look through non-PointerType constant expressions. (PR #125205)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 6 00:29:41 PST 2025


fhahn wrote:

> Say you have something like the following:
> 
> ```
> if ((uintptr_t)&g1 + 4 == (uintptr_t)&g2) {
>   *(int*)((uintptr_t)&g1 + 4) = 10;
> }
> ```
> 
> You have a write to g2, but the store itself doesn't mention g2 at all.
> 
> Maybe that's already broken even without your patch, though? I'm suspicious of the way "IsCompared" works.
> 
> If comparisons aren't involved, I guess it's safe to recurse through ptrtoint/inttoptr? At least, I can't come up with any way to break it in this context; like you say, it's conservatively correct.

Hmm I see. I assumed there's already code to rule out those cases. I checked and the compare based on integers is handled correctly by GlobalOpt due to considering `inttoptr/ptrtoint` as writing. For constant-expressions, that wouldn't hold as in the current patch. But if the `inttoptr/ptrtoint` is only applied to one of the globals, then we don't catch it: https://llvm.godbolt.org/z/Mxz8TMPvo

I think we can also run into this issue with non-inbounds GEPs unless I am missing something and that then wouldn't be handled correctly by GlobalOpt: https://llvm.godbolt.org/z/YroTa6Pc6

So with the change we would be incorrect in more cases. Maybe we need to be more careful with compares in general, and if any constant is involved we should make sure that the pointers on both sides are inbounds?

https://github.com/llvm/llvm-project/pull/125205


More information about the llvm-commits mailing list