[www] r327988 - [EuroLLVM'18] Program update.

Tue Mar 20 08:08:18 PDT 2018

Author: aadg
Date: Tue Mar 20 08:08:18 2018
New Revision: 327988

URL: http://llvm.org/viewvc/llvm-project?rev=327988&view=rev
Log:
[EuroLLVM'18] Program update.

Modified:
    www/trunk/devmtg/2018-04/index.html
    www/trunk/devmtg/2018-04/talks.html

Modified: www/trunk/devmtg/2018-04/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2018-04/index.html?rev=327988&r1=327987&r2=327988&view=diff
==============================================================================

--- www/trunk/devmtg/2018-04/index.html (original)
+++ www/trunk/devmtg/2018-04/index.html Tue Mar 20 08:08:18 2018
@@ -268,8 +268,6 @@ Power, Paul Bowen-Huggett.</li>
   <i>A. Guinet</i></li>
 <li><a href="talks.html#Lightning_5">Easy::Jit: Compiler-assisted library to enable Just-In-Time compilation for C++ codes</a>
   <i>J. Fernandez, S. Guelton</i></li>
-<li><a href="talks.html#Lightning_6">Efficient use of memory by reducing size of AST dumps in cross file analysis by clang static analyzer</a>
-  <i>S. Swain</i></li>
 <li><a href="talks.html#Lightning_7">Flang -- Project Update</a>
   <i>S. Scalpone</i></li>
 <li><a href="talks.html#Lightning_8">ISL Memory Management Using Clang Static Analyzer</a>

Modified: www/trunk/devmtg/2018-04/talks.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2018-04/talks.html?rev=327988&r1=327987&r2=327988&view=diff
==============================================================================
--- www/trunk/devmtg/2018-04/talks.html (original)
+++ www/trunk/devmtg/2018-04/talks.html Tue Mar 20 08:08:18 2018
@@ -546,94 +546,6 @@ framework to enable dynamic recompilatio
 information to improve the compiled code. This framework gives the user a clean
 abstraction and does not need to rely on specific compiler knowledge.</p>
 <hr>
-</td></tr><tr><td valign="top" id="Lightning_6">
-<b>Efficient use of memory by reducing size of AST dumps in cross file analysis by clang static analyzer </b><br>
-<i>S. Swain</i>
-<p>Clang SA works well with function call within a translation unit. When
-execution reaches a function implemented in another TU, analyzer skips analysis
-of called function definition. For handling cross file bugs, the CTU analysis
-feature was developed (Mostly by Ericsson people)[2]. The CTU model consists of
-two passes. The first pass dumps AST for all translation unit, creates a
-function map to corresponding AST. In the second pass when TU external function
-is reached during the analysis, the location of the definition of that function
-is looked up in the function definition index and the definition is imported
-from the containing AST binary into the caller's context using the ASTImporter
-class. During the analysis, we need to store the dumped ASTs temporarily. For a
-large code base this can be a problem and we have seen it practically where the
-code analysis stops due to memory shortage. Not only in CTU analysis but also
-in general case clang SA analysis reducing size of ASTs can also lead to
-scaling of clang SA to larger code bases. We are basically using two
-methods:-</p>
-
-<ol>
-<li>Using Outlining method[3] on the source code to find out AST that share
-  common factors or sub trees. We throw away those ASTs that won't match any
-  other AST, thereby reducing number of ASTs dumped in memory.</li>
-<li>Tree prunning technique to keep only those parts of tree necessary for
-  cross translation unit analysis and eliminating the rest to decrease the size
-  of tree. Finding necessary part of tree can be done by finding the dependency
-  path from the exploded graph where instructions dependent on the function
-  call/execution will be present. A thing to note here is that prunning of only
-  those branches whose no child is a function call should be done.</li>
-</ol>
-
-<p>Clang SA works well with function call within a translation unit. When
-execution reaches a function implemented in another TU, analyzer skips analysis
-of called function definition. For handling cross file bugs, the CTU analysis
-feature was developed (Mostly by Ericsson people)[2]. The CTU model consists of
-two passes. The first pass dumps AST for all translation unit, creates a
-function map to corresponding AST. In the second pass when TU external function
-is reached during the analysis, the location of the definition of that function
-is looked up in the function definition index and the definition is imported
-from the containing AST binary into the caller's context using the ASTImporter
-class. During the analysis, we need to store the dumped ASTs temporarily. For a
-large code base this can be a problem and we have seen it practically where the
-code analysis stops due to memory shortage. Not only in CTU analysis but also
-in general case clang SA analysis reducing size of ASTs can also lead to
-scaling of clang SA to larger code bases. We are basically using two
-methods:-</p>
-
-<ol>
-<li>Using Outlining method[3] on the source code to find out AST that share
-  common factors or sub trees. We throw away those ASTs that won't match any
-  other AST, thereby reducing number of ASTs dumped in memory.
-<li>Tree prunning technique to keep only those parts of tree necessary for
-  cross translation unit analysis and eliminating the rest to decrease the size
-  of tree. Finding necessary part of tree can be done by finding the dependency
-  path from the exploded graph where instructions dependent on the function
-  call/execution will be present. A thing to note here is that prunning of only
-  those branches whose no child is a function call should be done.
-</ol>
-
-<p>In CTU model in the first pass while dumping AST in memory the outlining
-algorithm can be applied to reduce the memory occupied by AST dumps. The
-outlining algorithm can be summarized by the following steps:- To reduce the
-size of the tree, we can eliminate ASTs that wonât match anything else in a
-first pass (that is, if you donât care about matching sub trees anyway). A
-hashing scheme that would store pointers to trees. Two trees would be in the
-same bucket if they could possibly match. They would be in different buckets if
-they definitely cannot match (like a bloom filter kind of setup). Then we can
-flatten the trees in each bucket, use the outlining technique there, and then
-end up with a factorization that way. </p>
-<ol>
-<li>Construct every AST.
-<li>Say two ASTs âcould be equalâ if they are isomorphic to each other.
-<li>Bucket each ASTs based off the âcould be equalâ scheme.
-<li>For each bucket with more than one entry, flatten out the ASTs and run the
-  outlining technique on the trees. 
-</ol>
-<p>At the end of each iteration, throw out the suffix tree built to handle the
-bucket. Here the main point to note here is that we are eliminating AST which
-wonât match anything, this reduces a large number of ASTs in memory. We are
-using a fast subtree isomorphism algorithm for matching ASTs which takes
-O((k^(1.5)/logk) n ) , where k and n are the numbers of nodes in two ASTs. For
-Tree pruning we are using the exploded graph concept to find the execution path
-when an externally defined function is called, focussing only on the variables
-or instructions which are affected as a result of that function call. We find
-like these all paths where an external function call is there, we keep these
-paths/branches in AST and eliminate all other branches of AST thereby reducing
-size of AST.</p>
-<hr>
 </td></tr><tr><td valign="top" id="Lightning_7">
 <b>Flang -- Project Update</b><br>
 <i>S. Scalpone</i>


