Previously, pointers obtained from/to inttoptr/ptrtoint are treated like arguments and globals. According to the Pointer Aliasing Rule section in LLVM Language Reference, inttoptr-pointers can only alias with values that it depends on. Therefore, it is ok to be less conservative by handling inttoptr and ptrtoint in the same way as we handle bitcasts.
Details
Diff Detail
Event Timeline
test/Analysis/CFLAliasAnalysis/int_ptr_cast.ll | ||
---|---|---|
13 | Consider the following testcase: %q = alloca i64, align 8 %qint = ptrtoint i64* %q to i64 %qint2 = add i64 %n, %qint %qint2 = sub i64 %n, %qint %qcast = inttoptr i64 %qint2 to i64* Suppose the function is then called with p==n. Then %qcast == %p. Also, it's possible to propagate a dependency through comparison instructions; consider, for example: void f(unsigned * p, unsigned n) { int q; int qint = (unsigned )&q; while (qint != n) ++qint; *(unsigned*)qint = 3; // modifies *p } |
test/Analysis/CFLAliasAnalysis/int_ptr_cast.ll | ||
---|---|---|
13 | Thank you so much for the comment! Your first example might unveil a bug in the codes (and another bug in my test). I think the current algorithm cfl-aa uses should be able to handle that, but it didn't. Your second example basically kills this patch. Control dependency is something that I failed to take into account. I'd like to argue that codes like that is very broken and should be fixed, but since this is permitted by the specification, for now it's not worth the pain to deal with it in any precise way. |
If this patch is obsolete, could you abandon it (choose "Abandon Revision" in the Action dropdown), please? :)
Consider the following testcase:
Suppose the function is then called with p==n. Then %qcast == %p.
Also, it's possible to propagate a dependency through comparison instructions; consider, for example: