Groups | Search | Server Info | Login | Register
Groups > comp.compilers > #3596
| Path | csiph.com!weretis.net!feeder9.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end |
|---|---|
| From | John R Levine <johnl@taugh.com> |
| Newsgroups | comp.compilers |
| Subject | preprint: The ART of Sharing Points-to Analysis |
| Date | Tue, 17 Sep 2024 14:08:57 -0400 |
| Organization | Compilers Central |
| Sender | johnl%iecc.com |
| Approved | comp.compilers@iecc.com |
| Message-ID | <24-09-003@comp.compilers> (permalink) |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset="UTF-8" |
| Injection-Info | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="59637"; mail-complaints-to="abuse@iecc.com" |
| Keywords | optimize |
| Posted-Date | 17 Sep 2024 14:15:20 EDT |
| X-submission-address | compilers@iecc.com |
| X-moderator-address | compilers-request@iecc.com |
| X-FAQ-and-archives | http://compilers.iecc.com |
| Xref | csiph.com comp.compilers:3596 |
Show key headers only | View raw
This paper proposes an improvement in "points-to" dataflow analysis, that they think will be useful in JIT compilers such as for Java. Data-flow analyses like points-to analysis can vastly improve the precision of other analyses, and help perform powerful code optimizations. However, whole-program points-to analysis of large programs tend to be expensive - both in terms of time and memory. Consequently, many compilers (both static and JIT) and program-analysis tools tend to employ faster - but more conservative - points-to analysis to improve usability. As an alternative to such trading of precision for performance, various techniques have been proposed to perform precise yet expensive fixed-point points-to analyses ahead of time in a static analyzer, store the results, and then transmit them to independent compilation/program-analysis stages that may need them. However, an underlying concern of safety affects all such techniques - can a compiler (or program analysis tool) trust the points-to analysis results generated by another compiler/tool? In this work, we address this issue of trust, while keeping the issues of performance efficiency in mind. We propose ART: Analysis-results Representation Template - a novel scheme to efficiently and concisely encode results of flow-sensitive, context-insensitive points-to analysis computed by a static analyzer for use in any independent system that may benefit from such a highly precise points-to analysis. Our scheme has two components: (i) a producer that can statically perform expensive points-to analysis and encode the same concisely. (ii) a consumer that, on receiving such encoded results, can regenerate the points-to analysis results encoded by the artwork if it is deemed safe. We demonstrate the usage of ART by implementing a producer (in Soot) and two consumers (in Soot and the Eclipse OpenJ9 JIT compiler). We evaluate our implementation over various benchmarks from the DaCapo and SPECjvm2008 suites. https://arxiv.org/abs/2409.09062 Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
Back to comp.compilers | Previous | Next | Find similar
preprint: The ART of Sharing Points-to Analysis John R Levine <johnl@taugh.com> - 2024-09-17 14:08 -0400
csiph-web