Demo Data from EDBT 2026 / reviewers in the wild / expert
Alexandros Lamprineas
dblp:169/6755
· DBLP profile ↗
1ranked-venue papers
0as first author
0since 2021 · last 2015
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Compilers and program optimization · 87% Program analysis · 13% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Compilers and program optimization
loop optimization |
0.2 | 1 | 2015 | Runtime pointer disambiguation · OOPSLA 2015 |
Compilers and program optimization › compiler analysis
pointer disambiguation |
0.2 | 1 | 2015 | Runtime pointer disambiguation · OOPSLA 2015 |
Program analysis › static analysis
pointer analysis |
0.1 | 1 | 2015 | Runtime pointer disambiguation · OOPSLA 2015 |
Methods — techniques the papers use, named apart from their topics
versioning · 0.2runtime checks · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2015 | Runtime pointer disambiguationabstractTo optimize code effectively, compilers must deal with memory dependencies. However, the state-of-the-art heuristics available in the literature to track memory dependencies are inherently imprecise and computationally expensive. Consequently, the most advanced code transformations that compilers have today are ineffective when applied on real-world programs. The goal of this paper is to solve this conundrum through dynamic disambiguation of pointers. We provide different ways to determine at runtime when two memory locations can overlap. We then produce two versions of a code region: one that is aliasing-free - hence, easy to optimize - and another that is not. Our checks let us safely branch to the optimizable region. We have applied these ideas on Polly-LLVM, a loop optimizer built on top of the LLVM compilation infrastructure. Our experiments indicate that our method is precise, effective and useful: we can disambiguate every pair of pointer in the loop intensive Polybench benchmark suite. The result of this precision is code quality: the binaries we generate are 10% faster than those that Polly-LLVM produces without our optimization, at the -O3 optimization level of LLVM. Péricles Rafael Oliveira Alves, Fabian Gruber, Johannes Doerfert, Alexandros Lamprineas, Tobias Grosser, Fabrice Rastello, Fernando Magno Quintão Pereira |
OOPSLA | 4 |