[cfe-dev] [LLVMdev] Clang devirtualization proposal

[Philip Reames]

Having read through the proposal, I feel like I missing some of the 
background to understand the problem you're trying to solve.

My mental model is that construction of an object creates a new abstract 
location in an infinite heap with each object infinitely far apart.  
Destruction of the object destroys the abstract location.  As a result, 
destructing one object and constructing another produce unique 
incomparable abstract locations.  The fact the two abstract locations 
might happen to share a physical address is irrelevant.

If I'm understanding the proposal correctly, this model works for most 
code.  The key optimization you appear to want to perform is to 
recognize the fact that these two abstract locations occupy the same 
memory.  In particular, you want to be able to return mustalias for 
alias(loc1, loc2).  Another way of saying this is that you want to 
reason about abstract locations as defined by allocation/deallocation 
events rather than construction/destruction events.  Is that a fair summary?

What I'm not clear on is *why* recognizing the two abstract locations 
share a physical address is important.  Given that the contents of the 
abstract location before construction or after destruction are undefined 
(right?), what optimization does recognizing the mustalias relation enable?

Philip


On 07/22/2015 02:55 PM, Piotr Padlewski wrote:
> Hi folks,
> this summer I will work with Richard Smith on clang devirtualization. 
> Check out our proposal:
>
> https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA_edit-3Fusp-3Dsharing&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-sGvXxkjadRLtXcTi4kOVPumoH-0XOKmk_vgUTcYugY&s=hHoo6tgC-NooXdIwbBwT_D8sIw8fcYF4XvBRI8Lr9Eg&e=>
>
> And modified LangRef
> http://reviews.llvm.org/D11399 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11399&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-sGvXxkjadRLtXcTi4kOVPumoH-0XOKmk_vgUTcYugY&s=L6_vdinD06uAwgm4OJGL5QxKw8Tzfa_4DxPwf3Zj704&e=>
>
> You can also check out previous disscussion that was started before 
> our proposal was ready - 
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html
>
> Regards
> Piotr Padlewski
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150728/222693e8/attachment.html>