CGO 2021
Sat 27 February - Wed 3 March 2021

Call for Papers

Call for Papers Including Call for Tool and Practical Experience Papers

The International Symposium on Code Generation and Optimization (CGO) is a premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization.

Original contributions are solicited on, but not limited to, the following topics:

  • Code Generation, Translation, Transformation, and Optimization for performance, energy, virtualization, portability, security, or reliability concerns, and architectural support
  • Efficient execution of dynamically typed and higher-level languages
  • Optimization and code generation for emerging programming models, platforms, domain-specific languages
  • Dynamic/static, profile-guided, feedback-directed, and machine learning based optimization
  • Static, Dynamic, and Hybrid Analysis for performance, energy, memory locality, throughput or latency, security, reliability, or functional debugging
  • Program characterization methods
  • Efficient profiling and instrumentation techniques; architectural support
  • Novel and efficient tools
  • Compiler design, practice and experience
  • Compiler abstraction and intermediate representations
  • Vertical integration of language features, representations, optimizations, and runtime support for parallelism
  • Solutions that involve cross-layer (HW/OS/VM/SW) design and integration
  • Deployed dynamic/static compiler and runtime systems for general purpose, embedded system and Cloud/HPC platforms
  • Parallelism, heterogeneity, and reconfigurable architectures
  • Optimizations for heterogeneous or specialized targets, GPUs, SoCs, CGRA
  • Compiler support for vectorization, thread extraction, task scheduling, speculation, transaction, memory management, data distribution and synchronization

Artifact Evaluation

The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. This process contributes to improve reproducibility in research that should be a great concern to all of us. There is also some evidence that papers with a supporting artifact receive higher citations than papers without (Artifact Evaluation: Is It a Real Incentive? by B. Childers and P. Chrysanthis).

Authors of accepted papers at CGO have the option of submitting their artifacts for evaluation within two weeks of paper acceptance. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information is available on the CGO AE web page. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library.


Call for Tools and Practical Experience Papers

Last year CGO had a special category of papers called “Tools and Practical Experience,” which was very successful. CGO this year will have the same category of papers. Such a paper is subject to the same page length guidelines, except that it must give a clear account of its functionality and a summary about the practice experience with realistic case studies, and describe all the supporting artifacts available.

For papers submitted in this category that present a tool it is mandatory to submit an artifact to the Artifact Evaluation process and to be successfully evaluated. These papers will initially be conditionally accepted based on the condition that an artifact is submitted to the Artifact Evaluation process and that this artifact is successfully evaluated. Authors are not required to make their tool publicly available, but we do require that an artifact is submitted and successfully evaluated.

Papers submitted in this category presenting practical experience are encouraged but not required to submit an artifact to the Artifact Evaluation process.

The selection criteria for papers in this category are:

  • Originality: Papers should present CGO-related technologies applied to real-world problems with scope or characteristics that set them apart from previous solutions.
  • Usability: The presented Tools or compilers should have broad usage or applicability. They are expected to assist in CGO-related research, or could be extended to investigate or demonstrate new technologies. If significant components are not yet implemented, the paper will not be considered.
  • Documentation: The tool or compiler should be presented on a web-site giving documentation and further information about the tool.
  • Benchmark Repository: A suite of benchmarks for testing should be provided.
  • Availability: Preferences will be given to tools or compilers that are freely available (at either the source or binary level). Exceptions may be made for industry and commercial tools that cannot be made publicly available for business reasons.
  • Foundations: Papers should incorporate the principles underpinning Code Generation and Optimization (CGO). However, a thorough discussion of theoretical foundations is not required; a summary of such should suffice.
  • Artifact Evaluation: The submitted artifact must be functional and supports the claims made in the paper. Submission of an artifact is mandatory for papers presenting a tool.

Authors should carefully consider the difference in focus with the co-located conferences when deciding where to submit a paper. CGO will make the proceedings freely available via the ACM DL platform during the period from two weeks before to two weeks after the conference. This option will facilitate easy access to the proceedings by conference attendees, and it will also enable the community at large to experience the excitement of learning about the latest developments being presented in the period surrounding the event itself.

Submission Site

Papers can be submitted at https://cgo21.hotcrp.com.

Submission Guidelines

Please make sure that your paper satisfies ALL of the following requirements before it is submitted:

  • The paper must be original material that has not been previously published in another conference or journal, nor is currently under review by another conference or journal. Note that you may submit material presented previously at a workshop without copyrighted proceedings.

  • Your submission is limited to ten (10) letter-size (8.5″x11″), single-spaced, double-column pages, using 10pt or larger font, not including references. There is no page limit for references. We highly recommend the IEEE templates for conference proceedings because this format will be used in the proceedings. The ACM SIGPLAN templates may also be used for reviews, and in that case, please use the following options: \documentclass[sigplan,10pt,review,anonymous]{acmart}\settopmatter{printfolios=true,printccs=false,printacmref=false}. Submissions not adhering to these submission guidelines may be outright rejected at the discretion of the program chairs. (Please make sure your paper prints satisfactorily on letter-size (8.5″x11″) paper: this is especially important for submissions from countries where A4 paper is standard.)

  • Papers are to be submitted for double-blind review. Blind reviewing of papers will be done by the program committee, assisted by outside referees. Author names as well as hints of identity are to be removed from the submitted paper. Use care in naming your files. Source file names, e.g., Joe.Smith.dvi, are often embedded in the final output as readily accessible comments. In addition, do not omit references to provide anonymity, as this leaves the reviewer unable to grasp the context. Instead, if you are extending your own work, you need to reference and discuss the past work in third person, as if you were extending someone else’s research. We realize in doing this that for some papers it will still be obvious who the authors are. In this case, the submission will not be penalized as long a concerted effort was made to reference and describe the relationship to the prior work as if you were extending someone else’s research. For example, if your name is Joe Smith:

    In previous work [1,2], Smith presented a new branch predictor for …. In this paper, we extend their work by …

    Bibliography

    [1] Joe Smith, “A Simple Branch Predictor for …,” Proceedings of CGO 2019.

    [2] Joe Smith, “A More Complicated Branch Predictor for…,” Proceedings of CGO 2019.

  • Your submission must be formatted for black-and-white printers and not color printers. This is especially true for plots and graphs in the paper.
  • Please make sure that the labels on your graphs are readable without the aid of a magnifying glass. Typically the default font sizes on the graph axes in a program like Microsoft Excel are too small.
  • Please number the pages.
  • The paper must be submitted in PDF. We cannot accept any other format, and we must be able to print the document just as we receive it. We strongly suggest that you use only the four widely-used printer fonts: Times, Helvetica, Courier and Symbol.
  • Please make sure that the output has been formatted for printing on LETTER size paper. If generating the paper using “dvips”, use the option “-P cmz -t letter”, and if that is not supported, use “-t letter”.
  • The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. Authors of accepted papers have the option of submitting their artifacts for evaluation within two weeks of paper acceptance. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information is available on the CGO AE web page. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library.
  • Authors must register all their conflicts on the paper submission site. Conflicts are needed to ensure appropriate assignment of reviewers. If a paper is found to have an undeclared conflict that causes a problem OR if a paper is found to declare false conflicts in order to abuse or “game” the review system, the paper may be rejected.

  • Please declare a conflict of interest with the following people for any author of your paper:

    • Your Ph.D. advisor(s), post-doctoral advisor(s), Ph.D. students, and post-doctoral advisees, forever.
    • Family relations by blood or marriage, or their equivalent, forever (if they might be potential reviewers).
    • People with whom you have collaborated in the last FIVE years, including:
    • Co-authors of accepted/rejected/pending papers.
    • Co-PIs on accepted/rejected/pending grant proposals.
    • Funders (decision-makers) of your research grants, and researchers whom you fund.
    • People (including students) who shared your primary institution(s) in the last FIVE years.
    • Other relationships, such as close personal friendship, that you think might tend to affect your judgement or be seen as doing so by a reasonable person familiar with the relationship.
    • “Service” collaborations such as co-authoring a report for a professional organization, serving on a program committee, or co-presenting tutorials, do not themselves create a conflict of interest. Co-authoring a paper that is a compendium of various projects with no true collaboration among the projects does not constitute a conflict among the authors of the different projects.
    • On the other hand, there may be others not covered by the above with whom you believe a COI exists, for example, an ongoing collaboration that has not yet resulted in the creation of a paper or proposal. Please report such COIs; however, you may be asked to justify them. Please be reasonable. For example, you cannot declare a COI with a reviewer just because that reviewer works on topics similar to or related to those in your paper. The PC Chair may contact co-authors to explain a COI whose origin is unclear.
    • We hope to draw most reviewers from the PC and the ERC, but others from the community may also write reviews. Please declare all your conflicts (not just restricted to the PC and ERC). When in doubt, contact the program co-chairs.