# Code Generation

**URL:** https://discourse.llvm.org/c/code-generation/51.md

[Latest](https://discourse.llvm.org/latest.md) · [Categories](https://discourse.llvm.org/categories.md) · [Tags](https://discourse.llvm.org/tags.md)

---

## [About the Code Generation category](https://discourse.llvm.org/t/about-the-code-generation-category/5134)

<div class="topic-metadata">

**Author:** [@tonic](https://discourse.llvm.org/u/tonic)\
**Replies:** 4\
**Last updated:** [January 11, 2022, 8:46pm UTC](https://discourse.llvm.org/t/about-the-code-generation-category/5134 "2022-01-11T20:46:25Z")

</div>

Discussion about code generation. Relevant topics include register allocation, instruction selection, instruction scheduling, late target-specific optimizations, and general backend work. Click here for documentation on …

---

## [Memory Corruption in LLVM](https://discourse.llvm.org/t/memory-corruption-in-llvm/91962)

<div class="topic-metadata">

**Author:** [@borisboesler](https://discourse.llvm.org/u/borisboesler)\
**Replies:** 2\
**Last updated:** [October 2, 2026, 8:49am UTC](https://discourse.llvm.org/t/memory-corruption-in-llvm/91962 "2026-10-02T08:49:51Z")

</div>

In my upgrade process I get a memory-corruption in LLVM in a test-case (sadly I can’t provide this test-case) I upgraded from 18.1.8 to 19.1.0 with only minor changes caused by my target - could be not enough changes. T…

---

## [Zicfilp func-sig label scheme conventions](https://discourse.llvm.org/t/zicfilp-func-sig-label-scheme-conventions/91949)

<div class="topic-metadata">

**Author:** [@Keksesser3000](https://discourse.llvm.org/u/Keksesser3000)\
**Replies:** 7\
**Last updated:** [October 2, 2026, 7:18am UTC](https://discourse.llvm.org/t/zicfilp-func-sig-label-scheme-conventions/91949 "2026-10-02T07:18:30Z")

</div>

I’m working on implementing the func-sig label scheme (-cf-protection=branch -cf-branch-label-scheme=func-sig) and there’s some open questions I wanted to discuss regarding labels that don’t correspond to a function at a…

---

## [\[RFC\] Renesas SuperH Backend](https://discourse.llvm.org/t/rfc-renesas-superh-backend/91836)

<div class="topic-metadata">

**Author:** [@LunaTheFoxgirl](https://discourse.llvm.org/u/LunaTheFoxgirl)\
**Replies:** 26\
**Last updated:** [October 1, 2026, 9:18am UTC](https://discourse.llvm.org/t/rfc-renesas-superh-backend/91836 "2026-10-01T09:18:56Z")

</div>

Currently working on a backend for the SuperH architecture and it has reached a milestone of supporting SH1 and 2. As such I’d like to propose merging this in as an experimental backend. SuperH is a bi-endian 32-bit arc…

---

## [mayLoad = 1 for RISCV PseudoLA instruction](https://discourse.llvm.org/t/mayload-1-for-riscv-pseudola-instruction/91964)

<div class="topic-metadata">

**Author:** [@IhrWerbepartner](https://discourse.llvm.org/u/IhrWerbepartner)\
**Replies:** 2\
**Last updated:** [October 1, 2026, 6:56am UTC](https://discourse.llvm.org/t/mayload-1-for-riscv-pseudola-instruction/91964 "2026-10-01T06:56:40Z")

</div>

Hi all, When looking at the current RISCV Backend Instruction Patterns in LLVM I noticed that the PseudoLA instruction specifies mayLoad = 1 while PseudoLLA sets this flag to mayLoad = 0. (PseudoLAImm also sets it to 0)…

---

## [\[RFC\] RISC-V: a target for software (interpreted) rather than hardware (executed)](https://discourse.llvm.org/t/rfc-risc-v-a-target-for-software-interpreted-rather-than-hardware-executed/91891)

<div class="topic-metadata">

**Author:** [@nazar-pc](https://discourse.llvm.org/u/nazar-pc)\
**Replies:** 13\
**Last updated:** [September 26, 2026, 2:41am UTC](https://discourse.llvm.org/t/rfc-risc-v-a-target-for-software-interpreted-rather-than-hardware-executed/91891 "2026-09-26T02:41:55Z")

</div>

RISC-V is increasingly not only a hardware target, but also a software one. It gets decoded and dispatched by an interpreter, or handed to a simple JIT. For that kind of consumer the cost of a program is roughly how many…

---

## [RISC-V LLVM sync-up call September 24th 2026](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-september-24th-2026/91910)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [September 23, 2026, 6:54pm UTC](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-september-24th-2026/91910 "2026-09-23T18:54:50Z")

</div>

We’ll meet as normal tomorrow, Thu 24th September at 4pm BST / 8am PDT. If you have more topics for the agenda please drop them in the doc.

---

## [LLVM ABI library support for AArch64](https://discourse.llvm.org/t/llvm-abi-library-support-for-aarch64/91777)

<div class="topic-metadata">

**Author:** [@andykaylor](https://discourse.llvm.org/u/andykaylor)\
**Replies:** 5\
**Last updated:** [September 21, 2026, 10:09pm UTC](https://discourse.llvm.org/t/llvm-abi-library-support-for-aarch64/91777 "2026-09-21T22:09:03Z")

</div>

I am posting here to raise awareness of the fact that I am currently in the process of adding AArch64 support to the LLVM ABI library. The LLVM ABI library is intended as a way to move the calling convention classificat…

---

## [Beginner guide for LLVM backend development for AArch64](https://discourse.llvm.org/t/beginner-guide-for-llvm-backend-development-for-aarch64/90999)

<div class="topic-metadata">

**Author:** [@Eagertolearn](https://discourse.llvm.org/u/Eagertolearn)\
**Replies:** 3\
**Last updated:** [September 21, 2026, 9:07am UTC](https://discourse.llvm.org/t/beginner-guide-for-llvm-backend-development-for-aarch64/90999 "2026-09-21T09:07:31Z")

</div>

Hello LLVM Community, I hope you’re doing well. I am a student, I have recently become interested in learning LLVM backend development, particularly the AArch64 backend. While I have some familiarity with compiler con…

---

## [\[RFC\] Exposing Pre-RA Scheduling for Search and ML Experimentation](https://discourse.llvm.org/t/rfc-exposing-pre-ra-scheduling-for-search-and-ml-experimentation/91705)

<div class="topic-metadata">

**Author:** [@choikwa](https://discourse.llvm.org/u/choikwa)\
**Replies:** 8\
**Last updated:** [September 11, 2026, 1:55pm UTC](https://discourse.llvm.org/t/rfc-exposing-pre-ra-scheduling-for-search-and-ml-experimentation/91705 "2026-09-11T13:55:14Z")

</div>

Hello everyone, I wanted to get some opinions on another possible entry point for search algorithms and ML-based experimentation in LLVM. I’ve been experimenting with pre-RA scheduling as a place to search for better r…

---

## [Remove Ventana Conditional Ops and Veyron V1 Defintion](https://discourse.llvm.org/t/remove-ventana-conditional-ops-and-veyron-v1-defintion/91694)

<div class="topic-metadata">

**Author:** [@bababuck](https://discourse.llvm.org/u/bababuck)\
**Replies:** 3\
**Last updated:** [September 10, 2026, 4:02pm UTC](https://discourse.llvm.org/t/remove-ventana-conditional-ops-and-veyron-v1-defintion/91694 "2026-09-10T16:02:19Z")

</div>

Not sure if this has already been discussed elsewhere (and I can bring it up at the next RISCV meeting), but I am hoping to remove support for the VentanaCondOps extension as well as the VentanaVeyronV1 processor definit…

---

## [RISC-V LLVM sync-up call Septemer 10th 2026](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-septemer-10th-2026/91780)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [September 10, 2026, 10:54am UTC](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-septemer-10th-2026/91780 "2026-09-10T10:54:58Z")

</div>

We’ll meet as normal today, Thu 10th September at 4pm BST / 8am PDT. If you have more topics for the agenda please drop them in the doc.

---

## [\[RFC\] AArch64: Ternary select-accumulate to SDOT lowering](https://discourse.llvm.org/t/rfc-aarch64-ternary-select-accumulate-to-sdot-lowering/91742)

<div class="topic-metadata">

**Author:** [@Dhushyanths](https://discourse.llvm.org/u/Dhushyanths)\
**Replies:** 0\
**Last updated:** [September 7, 2026, 8:28am UTC](https://discourse.llvm.org/t/rfc-aarch64-ternary-select-accumulate-to-sdot-lowering/91742 "2026-09-07T08:28:34Z")

</div>

Motivation Ternary quantized neural networks (BitNet b1.58, Bonsai) use weights constrained to {-1, 0, +1}, eliminating all multiplications in favor of select-accumulate operations. This is becoming a practical inference…

---

## [\[RFC\] Change MIR to use block arguments instead of phis](https://discourse.llvm.org/t/rfc-change-mir-to-use-block-arguments-instead-of-phis/91657)

<div class="topic-metadata">

**Author:** [@arsenm](https://discourse.llvm.org/u/arsenm)\
**Replies:** 6\
**Last updated:** [September 3, 2026, 12:56pm UTC](https://discourse.llvm.org/t/rfc-change-mir-to-use-block-arguments-instead-of-phis/91657 "2026-09-03T12:56:16Z")

</div>

Today’s MIR/gMIR represent SSA dataflow the same way as the IR, with PHI instructions. This RFC proposes to change MIR away from PHIs, and towards block arguments, as MLIR uses. This will help make a few register allo…

---

## [CANCELLED RISC-V LLVM sync-up call August 27th 2026](https://discourse.llvm.org/t/cancelled-risc-v-llvm-sync-up-call-august-27th-2026/91664)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [August 26, 2026, 4:24pm UTC](https://discourse.llvm.org/t/cancelled-risc-v-llvm-sync-up-call-august-27th-2026/91664 "2026-08-26T16:24:58Z")

</div>

We’ll skip the sync-up call tomorrow (August 27th) due to lack of topics, and some people being out on holidays. As always, feel free to queue up items in the doc

---

## [AArch64 Vector PCS on Darwin/Mach-O: support status and ABI contract?](https://discourse.llvm.org/t/aarch64-vector-pcs-on-darwin-mach-o-support-status-and-abi-contract/91663)

<div class="topic-metadata">

**Author:** [@blapie](https://discourse.llvm.org/u/blapie)\
**Replies:** 0\
**Last updated:** [August 26, 2026, 4:01pm UTC](https://discourse.llvm.org/t/aarch64-vector-pcs-on-darwin-mach-o-support-status-and-abi-contract/91663 "2026-08-26T16:01:27Z")

</div>

Hi, I’m trying to clarify the status of AArch64 Vector PCS (aarch64\_vector\_pcs) on Darwin, in particular for libraries exposing vector math functions. On ELF/AArch64, the ABI defines both the calling convention and the…

---

## [Shrink Wrap Save/Restore Points Splitting](https://discourse.llvm.org/t/shrink-wrap-save-restore-points-splitting/83581)

<div class="topic-metadata">

**Author:** [@enoskova-sc](https://discourse.llvm.org/u/enoskova-sc)\
**Replies:** 26\
**Last updated:** [August 25, 2026, 5:23pm UTC](https://discourse.llvm.org/t/shrink-wrap-save-restore-points-splitting/83581 "2026-08-25T17:23:06Z")

</div>

Motivation Currently ShrinkWrap pass produces maximum one Save and one Restore point, if managed to find. The Save point is chosen as NCD of BBs, in which some of the Calee Saved Registers are defined or used (or frame…

---

## [Per Processor Costing for RISCV](https://discourse.llvm.org/t/per-processor-costing-for-riscv/91575)

<div class="topic-metadata">

**Author:** [@bababuck](https://discourse.llvm.org/u/bababuck)\
**Replies:** 12\
**Last updated:** [August 24, 2026, 8:38pm UTC](https://discourse.llvm.org/t/per-processor-costing-for-riscv/91575 "2026-08-24T20:38:59Z")

</div>

RISC-V backends support a diverse range of targets, from simple in-order microprocessors to large out-of-order server chips. For instance, some chips may have multi-issue out-of-order scalar units with less powerful ve…

---

## [\[RFC\]\[Clang\]\[ARM\] Proactive stack overflow trapping for bare-metal Cortex-M](https://discourse.llvm.org/t/rfc-clang-arm-proactive-stack-overflow-trapping-for-bare-metal-cortex-m/91507)

<div class="topic-metadata">

**Author:** [@Acciente](https://discourse.llvm.org/u/Acciente)\
**Replies:** 3\
**Last updated:** [August 17, 2026, 8:39am UTC](https://discourse.llvm.org/t/rfc-clang-arm-proactive-stack-overflow-trapping-for-bare-metal-cortex-m/91507 "2026-08-17T08:39:59Z")

</div>

Motivation On low-end Cortex-M and similar bare-metal targets there is typically no MMU or MPU (memory protection unit). Stack overflow silently corrupts adjacent memory. This RFC proposes a function prologue check that …

---

## [RISC-V LLVM sync-up call August 13th 2026](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-august-13th-2026/91565)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [August 13, 2026, 12:22pm UTC](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-august-13th-2026/91565 "2026-08-13T12:22:50Z")

</div>

We’ll meet as normal today, Thu 13th August at 4pm BST / 8am PDT. If you have topics for the agenda please drop them in the doc. There’s not much on the agenda, but as we missed the last meeting I figured we’d see what …

---

## [\[wincall\] Propose a new x86\_64 windows calling convention wincall](https://discourse.llvm.org/t/wincall-propose-a-new-x86-64-windows-calling-convention-wincall/91548)

<div class="topic-metadata">

**Author:** [@trcrsired](https://discourse.llvm.org/u/trcrsired)\
**Replies:** 0\
**Last updated:** [August 11, 2026, 8:46pm UTC](https://discourse.llvm.org/t/wincall-propose-a-new-x86-64-windows-calling-convention-wincall/91548 "2026-08-11T20:46:17Z")

</div>

https://github.com/llvm/llvm-project/pull/215585 I am proposing a new x86\_64 windows calling convention wincall. See History: https://developercommunity.visualstudio.com/t/std::span-is-not-zero-cost-because-of-th/1429…

---

## [Error in backend: Can't handle live physical register dependency!](https://discourse.llvm.org/t/error-in-backend-cant-handle-live-physical-register-dependency/91083)

<div class="topic-metadata">

**Author:** [@borisboesler](https://discourse.llvm.org/u/borisboesler)\
**Replies:** 3\
**Last updated:** [July 30, 2026, 5:07pm UTC](https://discourse.llvm.org/t/error-in-backend-cant-handle-live-physical-register-dependency/91083 "2026-07-30T17:07:45Z")

</div>

I get an error in my closed-source backend: “Can’t handle live physical register dependency!” As far as I can see in debugging in ScheduleDAGRRList.cpp the physical register is the FLAG register, written by CMP and simi…

---

## [CANCELLED RISC-V LLVM sync-up call July 30th 2026](https://discourse.llvm.org/t/cancelled-risc-v-llvm-sync-up-call-july-30th-2026/91425)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [July 29, 2026, 3:33pm UTC](https://discourse.llvm.org/t/cancelled-risc-v-llvm-sync-up-call-july-30th-2026/91425 "2026-07-29T15:33:47Z")

</div>

We’ll skip the sync-up call tomorrow (July 30th) due to lack of topics, and some of us are traveling for an event. As always, feel free to queue up items in the doc

---

## [How to define multiple RegisterTuples for the same registers?](https://discourse.llvm.org/t/how-to-define-multiple-registertuples-for-the-same-registers/91354)

<div class="topic-metadata">

**Author:** [@egorshamshura](https://discourse.llvm.org/u/egorshamshura)\
**Replies:** 2\
**Last updated:** [July 22, 2026, 10:50am UTC](https://discourse.llvm.org/t/how-to-define-multiple-registertuples-for-the-same-registers/91354 "2026-07-22T10:50:30Z")

</div>

Hello everyone! I am working on instruction descriptions and have run into an issue with instructions that use a single operand representing multiple registers. For example, I have the following instruction: def GPRTr…

---

## [Apple ARM chips and BTI instruction - is it currently ignored for user apps, and why?](https://discourse.llvm.org/t/apple-arm-chips-and-bti-instruction-is-it-currently-ignored-for-user-apps-and-why/91346)

<div class="topic-metadata">

**Author:** [@gitevedev](https://discourse.llvm.org/u/gitevedev)\
**Replies:** 2\
**Last updated:** [July 20, 2026, 9:43pm UTC](https://discourse.llvm.org/t/apple-arm-chips-and-bti-instruction-is-it-currently-ignored-for-user-apps-and-why/91346 "2026-07-20T21:43:15Z")

</div>

Hello, TL;DR: How can i enable BTI checks for Mach-O binaries on macOS/iOS? There’s a clang option -mbranch-protection=btithat only generates bti instructions for indirect jumps, but they seem to be treated as nop’s whe…

---

## [\[RFC\] Improving LLVM Support for Alternative Constraints in GNU Extended Inline Assembly](https://discourse.llvm.org/t/rfc-improving-llvm-support-for-alternative-constraints-in-gnu-extended-inline-assembly/89350)

<div class="topic-metadata">

**Author:** [@void](https://discourse.llvm.org/u/void)\
**Replies:** 25\
**Last updated:** [July 15, 2026, 8:45pm UTC](https://discourse.llvm.org/t/rfc-improving-llvm-support-for-alternative-constraints-in-gnu-extended-inline-assembly/89350 "2026-07-15T20:45:45Z")

</div>

Abstract This document proposes a new mechanism for handling alternative constraints (i.e., "rm") in GNU-style extended inline assembly. The current approach relies on the frontend defaulting to the conservative choice, …

---

## [RISC-V LLVM sync-up call July 16th 2026](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-july-16th-2026/91311)

<div class="topic-metadata">

**Author:** [@asb](https://discourse.llvm.org/u/asb)\
**Replies:** 0\
**Last updated:** [July 15, 2026, 7:25pm UTC](https://discourse.llvm.org/t/risc-v-llvm-sync-up-call-july-16th-2026/91311 "2026-07-15T19:25:16Z")

</div>

We’ll meet as normal tomorrow, Thu 16th July at 4pm BST / 8am PDT. If you have topics for the agenda please drop them in the doc.

---

## [Dropping intrinsic arguments in tblgen (solved)](https://discourse.llvm.org/t/dropping-intrinsic-arguments-in-tblgen-solved/91281)

<div class="topic-metadata">

**Author:** [@fmayer](https://discourse.llvm.org/u/fmayer)\
**Replies:** 3\
**Last updated:** [July 14, 2026, 5:43pm UTC](https://discourse.llvm.org/t/dropping-intrinsic-arguments-in-tblgen-solved/91281 "2026-07-14T17:43:55Z")

</div>

Hey! I am working on a downstream LLVM target. We are modelling a handle to memory as a custom type, because it needs to be handled differently from other pointers in the backend. We have intrinsics to operate on those h…

---

## [\[RFC\] Keep the carry flag live across \_addcarry\_u64 loop back-edges (new late X86 pass)](https://discourse.llvm.org/t/rfc-keep-the-carry-flag-live-across-addcarry-u64-loop-back-edges-new-late-x86-pass/91267)

<div class="topic-metadata">

**Author:** [@rlanday](https://discourse.llvm.org/u/rlanday)\
**Replies:** 5\
**Last updated:** [July 11, 2026, 11:38pm UTC](https://discourse.llvm.org/t/rfc-keep-the-carry-flag-live-across-addcarry-u64-loop-back-edges-new-late-x86-pass/91267 "2026-07-11T23:38:54Z")

</div>

Hi all, I’d like to propose (and have implemented) a late X86 machine pass that removes a long-standing per-iteration penalty in multi-precision arithmetic loops, and I’d appreciate feedback on the approach before I ope…

---

## [Separating LLVM-MC](https://discourse.llvm.org/t/separating-llvm-mc/84781)

<div class="topic-metadata">

**Author:** [@KHDN](https://discourse.llvm.org/u/KHDN)\
**Replies:** 4\
**Last updated:** [July 3, 2026, 10:10am UTC](https://discourse.llvm.org/t/separating-llvm-mc/84781 "2026-07-03T10:10:22Z")

</div>

Hello friends, Good day, I want to separate the LLVM-MC module ( I don’t need whole LLVM in this project ) and use it in my project. I made many tries but I couldn’t some code are in main source and some are in the bu…

[Next page](https://discourse.llvm.org/c/code-generation/51.md?page=1)