Hi Rajiv,

Sorry for not replying sooner.  Thank you very much for your effort in 
submitting this patch.

I attended your presentation at the Open64 Developer's Forum and have been 
looking forward to trying out this new feature.  I read through all your files 
and did not detect any major problems.  I do have a few general comments:

1.       Whenever possible, please use common, defined macros (such as 
WN_num_dim(x)) instead of their equivalent expansion directly in the code.

2.       I noticed an inconsistency in using defined types such as BOOL, TRUE, 
FALSE, INT versus bool, true, false, int.  I saw both styles used in the files. 
 Please correct to follow the coding convention.

3.       Some minor cleanups such as unused variable definitions (variable "st" 
in line 914 of file constraint_graph.cxx, for example).

I consider these non-gating comments, and since there is interest in trying out 
this new feature, I encourage you to check in your patch - disabled, as you 
said, but with instructions on how to turn this feature on, so we can try it 
out and let you know of any bugs/further improvements.

Again, thank you very much for your patch.

Michael

From: Ravindran, Rajiv [mailto:ravind...@hp.com]
Sent: Friday, December 03, 2010 6:55 PM
To: Tianwei
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] nextgen alias analysis review request

Hi,

The AliasTag is a simple id associated with each WN. This is the basic 
interface to the generic AliasAnalyzer class. The NystromAliasAnalyzer which is 
an instance of the AliasAnalyzer, internally maps this to a sparse-bit vector 
of constraint graph node-ids.

We haven't changed anything that the current SSA based flow-sensitive alias 
analysis is doing. What we have added is another rule that queries the 
AliasAnalyzer using the alias tags on the POINTS_TO objects. This query will 
basically replace the current query to the alias classification analysis and is 
called only when all other rules return 'may alias' (see 
Aliased_Memop_By_Analysis in be/com/opt_alias_rule.cxx). So the graph in the 
slides is just comparing the results of the alias classifications analysis with 
the new implementation.

Thanks
Rajiv

From: Tianwei [mailto:tianwei.sh...@gmail.com]
Sent: Friday, December 03, 2010 6:33 PM
To: Ravindran, Rajiv
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] nextgen alias analysis review request


On Sat, Dec 4, 2010 at 9:48 AM, Ravindran, Rajiv 
<ravind...@hp.com<mailto:ravind...@hp.com>> wrote:
Hi,

Basically, it compares how precise we are w.r.t to alias classification. We 
measured the fraction of alias queries in BE for which we do not alias. As you 
can see, for C++ benchmarks we are not performing that well. There are several 
reasons for this -

1)      Alias classification is done after inlining and since we aren't 
context-sensitive yet we tend to be less precise.
OK, I understood that.

2)      Alias classification is called multiple times in BE and therefore is 
more up-to-date. We do not have this luxury since solving the constraint graph 
is more expensive. Moreover to make it worse, there are still a number of cases 
(after VHO/PreOpt) where after the transformation we no longer have the WN to 
AliasTag (point-to sets) mapping, and we end up being conservative. This is 
something we are currently looking at.
What does the AliasTag look like? A global id or a bit-vector like set? I may 
check your implementation

I think the SSA-based flow-sensitive alias analysis (or the base+offset+size 
rule) did a quite well job, if we can compare its result with your new Alias 
analysis result,  that will be great.  Although the field-sensitive alias 
analysis only work at intra-procedural level, we still can add a hook in the 
alias manager to see the effects that all existing alias facilities can not 
distinguish while new alias analysis can.


3)      We still have scalability issues in 483.xalancbmk. We have managed to 
address this by selectively "collapsing" objects - thus losing 
field-sensitivity. But more tuning is required.
Cool, that's great.

4)      Moreover, I believe this provides a better infrastructure to accurately 
compute mod/ref sets as well as improve the precision on memory SSA which can 
hopefully lead to better performance. So far we are only seeing minor 
improvements as shown in the same slide. Fortunately, we aren't degrading the 
performance :)

Agree, I am looking forward to that. We may get more interesting results based 
on your infrastructure.

Thanks
Rajiv


From: Tianwei [mailto:tianwei.sh...@gmail.com<mailto:tianwei.sh...@gmail.com>]
Sent: Friday, December 03, 2010 5:10 PM
To: Ravindran, Rajiv
Cc: 
open64-devel@lists.sourceforge.net<mailto:open64-devel@lists.sourceforge.net>
Subject: Re: [Open64-devel] nextgen alias analysis review request

Hi, Ravindran,
     Do you mind to explain a bit more for the page 18 of the slides?  what's 
the two bar? and what's the performance result?   If they are real running time 
improvement at IPA, since you can pass 483(especially with your 
field-sensitivity), that is really exciting.

     I will try to look at all your files later.

Tianwei
On Sat, Dec 4, 2010 at 5:51 AM, Ravindran, Rajiv 
<ravind...@hp.com<mailto:ravind...@hp.com>> wrote:
Hi folks,

Attached is a high-level design document describing our implementation of a new 
alias analysis infrastructure in Open64. Also included is the presentation we 
made of the same at the recent developer's forum. A patch containing the 
changes to the existing files is included in nextgenalias.diff, while the new 
files have been directly attached.

We plan to initially check this in disabled. Any comments or suggestions is 
greatly appreciated.

Thanks
Rajiv


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: New IBM DB2 features make compatibility easy.
Learn about native support for PL/SQL, new data types, scalar functions,
improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools,
best practices and more - all designed to run applications on both DB2 and
Oracle platforms. http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net<mailto:Open64-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/open64-devel



--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.



--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to