[LLVMdev] Expressing ambiguous points-to info in AliasAnalysis::alias(...) results?

[Daniel Berlin]

On Mon, Jun 15, 2015 at 7:25 AM, Christian Convey
<christian.convey at gmail.com> wrote:
> On Mon, Jun 15, 2015 at 9:31 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>> >> I tried to find some subset i felt was worthwhile and where it was
>> >> okay, but gave up after a while.
>> >
>> >
>> > I'm not quite sure which things you're referring to in that statement.
>> > Would you mind clarifying?
>>
>> You can try to ameliorate it by doing things like say "well, we
>> believe code  patterns that look like this generate valid pointers,
>> but patterns that look like this can be ignored".  It is very hard to
>> find a set of patterns you allow that gives you anything meaningfully
>
>
> Interesting.  So do you know of a decent alternative?  Or do you think that
> may-point-to analysis in something as general as LLVM IR is basically a dead
> end?

Points-to analysis on LLVM-IR itself is fine (see the current CFL-AA,
or the old deleted andersen's implementations), and giving may-alias
and no-alias results also works. Giving must-alias answers, however,
is difficult.

In particular, i would not simply ignore some types of constructs and
expect to produce valid answers.

>
> Also, can you share a few examples of code constructs which produce pointers
> used in correct programs, but which are hard to recognize statically?

There are plenty of things that are illegal in C but legal in LLVM IR.

For example, the following is legal LLVM IR (sorry for c style, it's early)

bar(int64 a) {
int64 * foo = inttoptr(a);
baz = load *foo;
}

This is not illegal, and will produce a valid result.

Same with stuff like:
bar(int64 *a) {
int64 foo = ptrtoint(a);
baz = foo + 5;
int64 *b = inttoptr(baz);
c = load *b;
}

Again, not illegal, and produces a valid result.
You can pretty much do what you want.

Things like "c pointer aliasing rules" exist only as metadata.
So in general, you can't expect "invalid pointers" to buy you very much.

>
> I did look at the LLVM IR for calling a virtual function in C++, since you
> mentioned that as an example earlier.  From manual inspection, I thought I
> could spot the value flow of the virtual function pointer from where the
> function was defined, into the vtable constant for that class, and then into
> the class instance's vtable pointer.

This depends on the frontend generating the llvm IR :)