The 2026 US LLVM Developers' Meeting will be held October 26–28 in Santa Clara, CA. All developers, researchers, and industry users of LLVM or any related subproject are invited to submit a proposal and share their work with one of the world's largest compiler communities.

Submit your talk proposal by July 14, 2026 (end of day AoE)  | Questions? Email events@llvm.org.

WHAT WE'RE LOOKING FOR

Technical Talks (20 minutes) 20-minute deep dives spanning core infrastructure to real-world projects built on LLVM  including new projects, industry use cases, and academic research.

Tutorials (40–50 minutes*) Go deep on LLVM infrastructure, core libraries, or tooling with detailed examples and explanations. Demos are strongly encouraged.

Student Technical Talks (15 minutes) A dedicated space for the next generation of LLVM contributors to present research using LLVM, Clang, or related subprojects. This is not a competition, but a chance to share your work and connect with the community.

Lightning Talks (5 minutes) Fast, punchy, and curiosity-sparking. A high-energy way to get your idea or project in front of the community.

Quick Talks (10 minutes) Got more to say than a lightning talk allows? These focused sessions give a topic the space to go deeper with room for technical detail, but without the full length of a technical talk.

Panels (45 minutes*) Lively discussions among experts, shaped in real time by audience questions and interests. Panels should include 3–5 people and a moderator.

Poster Present your work during the dedicated poster session. This is a great way to spark one-on-one conversations with attendees.

IMPORTANT DETAILS

Submission Deadline: July 14, 2026 (end of day AoE)

Notifications Sent: July 30, 2026

  • Session lengths marked with * are approximate and may be adjusted once the full schedule is planned.
  • Speakers must present in person. There is no option for virtual or recorded presentations. 
  • One 50% discounted conference registration for speakers is limited to: Technical Talks, Tutorials, Student Talks, Panels
    • There is no discounted registration for posters, lighting talks or quick talks.
  • If your accepted talk is not in one of those categories with discounted registration, please reach out if you need financial support for registration.

For each proposal you must submit the following:

  • Talk title
  • Abstract
  • Submission type
    • For technical talk submissions, you can indicate if you would give a shorter talk (ie. Lightning or Quick instead of full length Technical Talk)
  • Photo and bios for all speakers (required)
  • Short abstract for the website/program
  • Extended PDF abstract (optional)

Submissions without the required information may not be accepted.

GUDE TO WRITING A PROPOSAL FOR THE LLVM DEVELOPERS' MEETING

This is a guide to help you submit the best proposal and increase your chances of your proposal being accepted. The LLVM Developers’ Meeting program committee receives more proposals than can be accepted, so please read this guide carefully.

If you have never presented at an LLVM Developers’ Meeting, then do not fear this process. We are actively looking for new speakers who are excited about LLVM and helping grow the community through these educational talks! You do not need to be a long time developer to submit a proposal.

General Guidelines:

  • It should be clear from your abstract what your topic is, who your targeted audience is, and what are the takeaways for attendees. The program committee gets a lot of proposals and does not have time to read 10 page papers for each submission.
  • Talks about a use of LLVM (etc) should include details about how LLVM is used and not only be about the resulting application.
  • Tutorials on “how to use X” in LLVM (or other subproject) are greatly desired and beneficial to many developers. Entry level topics are encouraged as well.
  • Talks that have been presented at other technical conferences tend to not get accepted. If you have presented this topic before, make it clear what is new and different in your talk.

Guide to Proposal Fields:

TitleThis will be displayed on the website, schedule, and signs. Keep it short and catchy to attract attendees to your talks. A couple of examples are “WebAssembly: Here Be Dragons” or “Beyond Sanitizers: guided fuzzing and security hardening”.

AbstractHere you can include details about your talk. An outline, demo description, what takeaways will your audience have, etc. 1-2 paragraphs is sufficient usually.

This section will not be published and is intended for the PC to better understand how interesting your talk will be to the audience. For example, if you would prefer not to reveal some conclusions in the published abstract, explaining them here ensures that the PC can take them into account when evaluating your proposal.

SubmissionOptional PDF containing extended details. This is in addition to the abstract. Keep in mind that the program committee does not have time to read 10 page papers for each proposal. 

Authors: Anyone who is an author of the work or the proposal. We do blind submission, so the program committee will not see this information

Website Abstract1 paragraph. This is displayed on the schedule and website for attendees to consider when selecting talks.
We suggest you proofread and pay attention to grammar.

What type of talk submission is thisHere you can select the type of talk you are proposing. 

For technical talks, are you open to a shorter length talkThis applies only to those proposing a technical talk (20 minutes). Often we have space for shorter talks (5 or 10 min), so please indicate if you are open to giving a shorter talk on this topic instead. 

Speaker Name(s), Photo, Bio (up to 5 for panels including the moderator)This should be only the people giving the talk. Typically this is 1 or 2 people for longer talks, and only 1 for shorter length. This is not shared with the program committee. It is used by the logistics team to populate the speaker page on the event site and get speakers registered. This is required information as it takes longer to add speaker information after the fact. For panels, please determine your panelists and moderator at the time of submission.

Which speaker is your moderator? (PANELS ONLY, all others write N/A) List the moderator name. The program committee does not see this.

PC conflictsCheck any conflicts with program committee members. These are people that can not be impartial when reviewing your proposal. See HotCRP for the full definition of conflict. 

The submission is completeYou must check this when your proposal is final and ready for review. This allows the program 
committee to start reviewing proposals as soon as they are completed and not wait until the submission deadline. So please click this when you are ready for review.