Languages, Compilers, Tools and Theory of Embedded Systems (2026)LCTES 2026

LCTES 2026

Welcome to the 27th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES 2026)!

LCTES provides a link between the programming languages and embedded systems engineering communities. Researchers and developers in these areas are addressing many similar problems but with different backgrounds and approaches. LCTES is intended to expose researchers and developers from either area to relevant work and interesting problems in the other area and provide a forum where they can interact.

LCTES 2026 is co-located with and shares the venue and activities with PLDI 2026.

The important dates are as follows:

• Abstract Submission Deadline: March 13, 2026 (AoE) March 6, 2026 (AoE)
• Paper Submission Deadline: March 20, 2026 (AoE) March 13, 2026 (AoE)
• Paper Notification: May 1, 2026 (AoE)
• Conference Dates: June 15–16, 2026

If you have questions, you can contact the PC chairs.

Accepted Papers

	Title
	A Functional Approach to Synthesizing Routable Programmable Accelerators for Neural Networks LCTES Tzung-Han Juang, Paul Teng, Christophe Dubach DOI
	A Pointer-Ownership Model for C Inspired by Rust LCTES David Svoboda, William Klieber, Lori Flynn, Ruben Martins, Jeffrey Hoskinson DOI
	A Programming Model for Efficient Inter-Kernel Control-Flow on Memory-Mapped Near-Data Processing Architecture (WIP) LCTES Seungheon Lee, Wonhyuk Yang, Seonyeong Heo, Gwangsun Kim DOI
	Bridging the Memory Hotness Gap in Edge Systems with Hotness-Segregated Object Allocation LCTES Ruizhe Huang, Jiahua Wang, Qihang Xu, Peng Jiang, Zhida An, Ding Li, Yao Guo, Xiangqun Chen, Yuxin Ren, Ning Jia DOI
	Can Fine-Grain Multi-threading Subsume VLIW? LCTES Scott Pomerville, Soner Onder, Gang-Ryung Uh, David Whalley DOI
	CausalTuner: Feature-Aware Causal Guidance for Compiler Auto-tuning LCTES Jiaqing Zhong, Juan Chen, Yichang Zhou, Kuan Li DOI
	CVS: A Metric for Security-Aware Compilation against Side-Channel Attacks in Edge SoCs (WIP) LCTES Yi Han, Puhong Lei, Yang Shi, Zhe Li, Xing Mou, Jianjun Chen, Yaohua Wang DOI
	DeduBB: Binary Code Size Reduction via Post-Link Basic Block Deduplication LCTES Chaitanya Mamatha Ananda, Mahbod Afarin, Rajiv Gupta, Sriraman Tallam, Han Shen, Xinliang Li DOI
	Empirical Observations about Profile-Guided Optimizations for Mainstream C/C++ Compilers LCTES Soma Pal, Prasad Kulkarni DOI
	FLUX: Frequency Scaling with Layer-wise Utilization for Energy-Efficient NPU Execution (WIP) LCTES Inho Lee, Ky Yeop Lim, Hyejun Kim, Beomseok Kim, Dongsuk Jeon, Hunjun Lee, Yongjun Park DOI
	Hikami: A Lightweight Hypervisor for Emulating RISC-V Extension Semantics with Sail-Driven Auto-generation LCTES Norimasa Takana, Yoshihiro Oyama DOI
	LoopHint: A Compiler-Assisted Loop Branch Predictor for Embedded DSPs LCTES Yuanyang Xiang, Chen Xu, xiaoruozhou , Zhiwei Zhang DOI
	MemSpec: Memory-Aware Runtime for Adaptive Draft Scheduling in Speculative Decoding on Edge Devices LCTES Eunjeong Kim, Yeong Jun Jeon, Myeonggyun Han DOI
	On the Origins of Indirect Jumps in Embedded Software LCTES Ariane Nicolas, Ronan Lashermes, Isabelle Puaut, Erven Rohou DOI
	Practical Quantum Machine Learning: Overcoming the Bottlenecks of Scalability and Stability LCTES Aviral Shrivastava File Attached
	RAPO: Retrieval-Augmented Phase Ordering LCTES Jinwook Yang, Junghyun Lee, Yeonsun ­Hong, Hyojin Sung DOI
	Scheduled Partial-Credit RL for Reliable Code Generation with Small Language Models (WIP) LCTES Suryansh Singh Sijwali, Suman Saha DOI
	Sirop: A Small IR for HLS with Parallel Patterns LCTES Louis Hildebrand, Christophe Dubach DOI
	SymFlow: Event-Chain-Aware Symbolic Execution for Serverless Sensitive Data Flow Detection LCTES Yuanpeng Wang, Zhineng Zhong, Zhenkai Liang, Ding Li, Yao Guo, Xiangqun Chen DOI
	Towards Verifiable System Code using a DSL Compiled to Efficient and Readable C Code LCTES Clément Chavanon, Henrik Karlsson, Frédéric Besson, Sandrine Blazy, Roberto Guanciale DOI

Call for Papers

Programming languages, compilers, and tools are important interfaces between embedded systems and emerging applications in the real world. Embedded systems are aggressively adapted for deep neural network applications, large language models, autonomous vehicles, robots, healthcare applications, etc. However, these emerging applications impose challenges that conflict with conventional design requirements and increase the complexity of embedded system designs. Furthermore, they exploit new hardware paradigms to scale up multicores (including GPUs and FPGAs) and distributed systems built from many cores. Therefore, programming languages, compilers, and tools are becoming more important to address these issues, such as productivity, validation, verification, maintainability, safety, and reliability for meeting both performance goals and resource constraints.

The 27th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, Tools and Theory of Embedded Systems (LCTES 2026) solicits papers presenting original work on programming languages, compilers, tools, theory, and architectures that help in overcoming these challenges. Research papers on innovative techniques are welcome, as well as experience papers on insights obtained by experimenting with real-world systems and applications. Papers can be submitted to https://lctes2026.hotcrp.com/.

Important Dates

• Abstract Submission: March 6, 2026
• Paper Submission: March 13, 2026 
• Conference Dates: June 15–16, 2026

See the sidebar for more important dates.

Paper Categories

• Full paper: 10 pages presenting original work. References and appendixes are not counted towards the page limit
• Poster, work-in-progress and invited paper: 4 pages papers (incl. references/appendix) presenting original ideas that are likely to trigger interesting discussions.

Accepted papers in both categories will appear in the proceedings published by ACM. In addition, this year’s LCTES will have Distinguished Paper awards selected from this year’s accepted paper to recognize the outstanding work among all papers.

Topics

Original contributions are solicited on the topics of interest including, but not limited to:

Programming language challenges

• Domain-specific languages
• Features to exploit multicore, reconfigurable, and other emerging architectures
• Features for distributed, adaptive, and real-time control embedded systems
• Capabilities for specification, composition, and construction of embedded systems
• Language features and techniques to enhance reliability, verifiability, and security
• Virtual machines, concurrency, inter-processor synchronization, and memory management
• Compiler challenges

Interaction between embedded architectures, operating systems, and compilers

• Interpreters, binary translation, just-in-time compilation, and split compilation
• Support for enhanced programmer productivity
• Support for enhanced debugging, profiling, and exception/interrupt handling
• Optimization for low power/energy, code/data size, and real-time performance
• Parameterized and structural compiler design space exploration and auto-tuning
• Tools for analysis, specification, design, and implementation, including:
• Hardware, system software, application software, and their interfaces
• Distributed real-time control, media players, and reconfigurable architectures
• System integration and testing
• Performance estimation, monitoring, and tuning
• Run-time system support for embedded systems
• Design space exploration tools
• Support for system security and system-level reliability
• Approaches for cross-layer system optimization
• Theory and foundations of embedded systems

Predictability of resource behavior: energy, space, time

• Validation and verification, in particular of concurrent and distributed systems
• Formal foundations of model-based design as the basis for code generation, analysis, and verification
• Mathematical foundations for embedded systems
• Models of computations for embedded applications
• Novel embedded architectures

Design and implementation of novel architectures

• Workload analysis and performance evaluation
• Architecture support for new language features, virtualization, compiler techniques, debugging tools
• Architectural features to improve power/energy, code/data size, and predictability
• Mobile systems and IoT

Operating systems for mobile and IoT devices

• Compiler and software tools for mobile and IoT systems
• Energy management for mobile and IoT devices
• Memory and IO techniques for mobile and IoT devices

Large language models (LLMs) and programming languages/compilers

• Impact of LLMs on embedded system design and architectures
• LLM-based debugging tools for embedded software
• Adapting LLMs for resource-constraint environment
• LLM for embedded systems and compilers
• LLM for program analysis, testing and verification.
• Program analysis, testing and verification for LLM

Call for Artifacts

Submission Site

Submit your artifacts through https://lctes2026ae.hotcrp.com.

See the sidebar for the Important Dates.

General Info

The authors of all accepted LCTES papers (including WIP papers) are invited to submit supporting materials to the Artifact Evaluation process. Artifact Evaluation is run by a separate Artifact Evaluation Committee (AEC) whose task is to assess how well the artifacts support the work described in the papers. This submission is voluntary but strongly encouraged and will not influence the final decision regarding the papers.

At LCTES, we follow ACM’s artifact review and badging policy, version 1.1. ACM describes a research artifact as follows:

By “artifact” we mean a digital object created by the authors to be used as part of the study or generated by the experiment itself. For example, artifacts can be software systems, scripts used to run experiments, input datasets, raw data collected in the experiment, or scripts used to analyze results.

Submission of an artifact does not imply automatic permission to make its content public. AEC members will be instructed that they may not publicize any part of the submitted artifacts during or after completing the evaluation, and they will not retain any part of any artifact after evaluation. Thus, you can include models, data files, proprietary binaries, and similar items in your artifact.

We expect each artifact to receive three reviews. Papers that pass the Artifact Evaluation process will receive up to three ACM artifact evaluation badge(s) directly printed on the paper and available as meta information in the ACM Digital Library.

Artifact evaluation is single-blind. Please take precautions (e.g., turning off analytics and logging) to help prevent accidentally learning the reviewers’ identities.

Badging

The papers with accepted artifacts will be assigned official ACM artifact evaluation badges based on the criteria defined by ACM. The AEC awards up to three types of badges that reflect the evaluation (red), availability (green), and validation (blue) of the artifact and the results of the paper. Refer to the ACM website for detailed badge information. Note that artifacts will be evaluated with respect to the claims and presentation in the submitted version of the paper, not the camera-ready version.

The awarded badges will appear on the first page of the camera-ready version of the paper. Artifact authors will be allowed to revise their camera-ready paper after being notified of their artifact’s publication to include a link to the artifact’s DOI.

Note that we only award the “Reproducibility” (dark blue) badge (i.e., artifacts provided by authors) but not the “Replication” (light blue) badge (i.e., independent study without the use of author-supplied artifacts).

Guidelines

1. Carefully think which badge(s) you seek to receive.
   • If your only goal is to publish your code, seek the “Availability” (green) badge. The reviewers will not exercise the artifact for its functionality or validate the paper’s claims.
   • If you wish you have your results reproduced without making your artifact documented, consistent, complete, and exercisable, seek the “Reproducibility” (blue) badge rather than the “Functionality/Reusability” (red) badge.
   • If you do not want to make the artifact available publicly, do not seek the “Availability” (green) badge.
2. Minimize the artifact setup overhead.
   • A well-packaged artifact is easily usable by the reviewers and conveys the value of your work. A great way to package an artifact is as a VM image or Docker container that runs “out of the box.” We encourage authors to include pre-built binaries along with the source and build scripts that allow the AEC to regenerate the binaries to guarantee maximum transparency. Pre-built VM or docker images are preferred over scripts that build the image since this alleviates reliance on external dependencies. Make sure to test your artifact on at least one machine different than the one you used to prepare the artifact to identify missing dependencies.
   • Giving AE reviewers remote access to your machines with preinstalled (proprietary) software is possible.

Preparing the Artifact

You should make your artifact available as a single archive file and use the naming convention <paper #>.<suffix>, where the appropriate suffix is used for the given archive format. Use a commonly-available compressed archive format such as .tgz, .tbz2, or .zip and open document formats. The link to download your artifact must protect the anonymity of the reviewers (e.g., a Google Drive URL).

The compressed archive should consist of three pieces:

1. The submitted version of your accepted paper.
2. A README file (PDF or plaintext format) that explains your artifact (details below).
3. A folder containing the artifact.

The README.txt should consist of two parts:

1. A Getting Started Guide and
2. Step-by-Step Instructions that detail how your artifact can be evaluated. Include appropriate references to the relevant sections of your paper.

The Getting Started Guide should contain instructions on how to set up (including, for example, a pointer to the VM player software, its version, and passwords if needed) and test your artifact. Anyone following this guide should be able to handle the rest of your artifact easily.

The Step-by-Step Instructions explain how to reproduce experiments or other activities supporting your paper’s conclusions. Write this for readers who are deeply interested in your work and are studying to improve or compare against it. If your artifact runs for more than a few minutes, point this out and explain how to run it on smaller inputs.

Where appropriate, include descriptions of and links to files (included in the archive) that represent the expected outputs such as log files generated by your tool for a given set of inputs. If there are warnings that can be ignored, explain what they are.

Further, include the following:

• A list of claims from the paper supported by the artifact. Explain how and why the artifact supports those claims.
• A list of claims from the paper not supported by the artifact. Explain why the artifact does not support those claims. Examples: performance claims cannot be reproduced in a VM, authors cannot redistribute specific benchmarks, etc.

When preparing your artifact, please keep in mind:

• How accessible you are making your artifact to other researchers.
• The AEC members will have a limited time to assess your artifact.

Artifact Evaluation Committee

Other than the chair, the AEC members are senior graduate students, recent Ph.D. graduates, or postdocs. Please check SIGPLAN’s Empirical Evaluation Guidelines for some methodologies to consider during evaluation.

Throughout the review period, reviews will be submitted to HotCRP and continuously visible to authors. AEC reviewers will be able to continuously interact (anonymously) with authors for clarifications, system-specific patches, and other logistics to help ensure that the artifact can be evaluated. Continuous interaction prevents rejecting artifacts for “wrong library version” types of problems.

Artifact Evaluation Co-Chairs:

• Benedict Herzog
• Peter Wägemann

Members of Evaluation Committee:

• Alexandre Honorat (INRIA)
• Alwin Berger (Technische Universität Dortmund)
• Emad Jacob Maroun (Technical University of Denmark)
• Hwisoo So (Kyungpook National University)
• Jongouk Choi (University of Central Florida)
• Manuel Vögele (Ruhr University Bochum (RUB))
• Mehran Alidoost Nia (Shahid Beheshti University)
• Seonyeong Heo (Kyung Hee University)
• Tianyu Wang (Shenzhen University)
• Tzung-Han Juang (McGill University)

The AE process is non-competitive and success-oriented; our goal is that all submitted artifacts successfully pass the artifact evaluation.

Submission

Submissions must be in ACM SIGPLAN subformat of the acmart format (available at and explained in more detail at https://www.sigplan.org/Resources/Author/). Each paper should be in 10pt font and have no more than 10 pages for full papers or 4 pages for work-in-progress papers. For full papers, there is no page limit on the page count for references or the appendix. The citations should be in numeric style, e.g., [52]. Submissions must be in PDF format and printable on US Letter and A4-sized paper. For papers in the work-in-progress category, add the suffix “(WIP)” to your title, such as “Title (WIP)”.

Format your submission with two-column ACM SIGPLAN article style (e.g. acmart LaTeX style with options sigplan,anonymous,review,10pt). You may exclude topmatter and ACM copyright notice for the submission:

\documentclass[sigplan, anonymous, nonacm, review, 10pt]{acmart}
\acmConference[LCTES '26]{The 27th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, Tools and Theory of Embedded Systems}{June 2026}{Boulder, Colorado, United States}
\acmYear{2026}
\acmISBN{978-x-xxxx-xxxx-x/26/06}
\acmDOI{10.1145/xxxxxxx.xxxxxxx}
\copyrightyear{2026}
% For Review: Suppress the "ACM Reference Format" text block
\settopmatter{printacmref=false,printccs=false}
% For Review: Supress copyright notice for the reviewing
\setcopyright{none}

Double Blind Reviewing

To enable double-blind reviewing, submissions must adhere to two rules:

• author names and their affiliations must be omitted; and,
• references to related work by the authors should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”).

However, nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). Papers must describe unpublished work that is not currently submitted for publication elsewhere as discussed here. Authors of accepted papers will be required to sign an ACM copyright release.

ACM Publications Policies

1. By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.

2. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start, and we have recently made a commitment to collect ORCID IDs from all of our published authors. The collection process has started and will roll out as a requirement throughout 2022. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.

AUTHORS TAKE NOTE

All papers will be archived by the ACM Digital Library. Authors will have the option of including supplementary material with their paper. The official publication date is the date the proceedings are made available in the ACM Digital Library or the first day of the conference, which ever is sooner. Note that the date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work.

By submitting the paper, the authors agree that if the paper is accepted, one author will have to register at the conference rate and present the paper in person at the LCTES 2026 conference.

Submission site

https://lctes2026.hotcrp.com

Acknowledgments

This submission page is an adaptation and evolution of content from previous SIGPLAN conferences. We are grateful to prior organizers for their work, which is reused here.

This document is for those presenting a paper at LCTES ’26. If you’re presenting at PLDI, or PLDI tutorial/workshop, please see the Speaker’s Guide on the page for the corresponding conference/track.

Congratulations on having your paper accepted at LCTES ’26! This document will help ensure your presentation runs smoothly and has the best possible audience impact. Please read it in its entirety.

Checklist

Before LCTES:

• Prepare and practice.
• Each regular paper’s presentation slot lasts for 20 minutes, including 17 minutes of presentation and 3 minutes of Q&A.
• Each WIP paper’s presentation slot lasts for 10 minutes, including 7 minutes of presentation and 3 minutes of Q&A.
• Check the program to establish when and where your talk will be.
• Ensure you have an HDMI adaptor for your device.

Before your talk:

• Familiarize yourself with the room you will be speaking in.
• Find and introduce yourself to your session chair.
• Ensure that you are in the room no later than 5 minutes before your session.

After your talk:

• Expect questions from the floor and the session chair.

Preparing Your Talk

Your work will have a greater impact if you’re well prepared.

It is very important that you run to schedule. The LCTES ’26 schedule is extremely tight, and thus session chairs have been asked to stick rigidly to the schedule.

Guidelines

1. Your talk should run for no more than the allocated time (i.e., 17 minutes for full papers, 7 minutes for WIP papers), uninterrupted. This gives you about three minutes for questions and speaker changeover.
2. Your talk should be prepared for the standard 16:9 widescreen ratio. If your talk is in a different ratio, at best it will be pillarboxed, wasting screen real estate and diminishing impact, and at worst, it won’t display correctly.
3. You will present your talk from a lectern, using a fixed lectern mic.
4. You will need to provide your talk ahead of time in either PDF or PowerPoint.

Advices

There are many excellent sources of advice on giving good talks, including from Simon Peyton Jones, Michael Hicks, Michael Ernst, and Derek Dreyer. Make good use of these!

Q&A

If you stick to the above schedule, you will have about 3 minutes for questions. The in-room audience will be able to ask questions via a queue at a single microphone on a mic stand in the center of the room.

It is good practice, as the speaker, to repeat your understanding of the question before providing your answer. This is particularly important when time is tight because it reduces opportunities for time being wasted on account of a misunderstanding.