[llvm-dev] Existing studies on the benefits of pointer analysis

[Chris Lattner via llvm-dev]

On Mar 28, 2016, at 9:32 AM, Jia Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> Can you elaborate on what you mean by flow sensitive? We have a mod/ref query interface that can return answers specific to a particular instruction/call pair. The code above could easily live in a single basic block, and if we had function attribute deduction on the 'argmemonly' attribute, we could probably do this now.
>> 
>>  -Hal
> 
> What I meant is that the CSE needs to be aware of the execution order, i.e. the call to V1.pop_back() should not be in the middle of the two V1.size() for zero to be 0. If there exists more complicated control flows, CSE needs to be able to make the same kind of argument across basic blocks.
> 
> I didn't follow LLVM development very closely to be familiar with how LLVM handles CSE. If what I said above is exactly how it works today, then yes we could probably do this now.

The existing LLVM passes and infrastructure already do this.

> But still, there is no APIs that answers "are p and q aliases before this instruction x?". The same can be done for mod-ref today (if I remembered correctly this isn't even the case before the AAResult class came into existence), but not for aliases. 

This is already handled correctly by LLVM.  The sequence in question is:

>> auto length = V1.size();

“V1.size()” (which is effectively a load) is available after this instruction.

>> V2.pop_back();    // Mutates *this

Alias analysis is queried to say “does std::vector::pop_back(&V2) mod/ref &V1”?

If it returns mod, then “length” is removed from the available set.

>> auto zero = length - V1.size()


The access to V1.size() also a load, if it is in the available set, it is replaced with the SSA value for “length”.  A later simplification pass turns "length-length" into 0, allowing the original load to be removed as dead.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/bd744a6a/attachment-0001.html>