Eliminate Branches by Melding IR Instructions

Modern processors use deep pipelines and speculative execution to achieve high instructions-per-cycle (IPC). When encountering a conditional branch, the processor must predict its direction and speculatively fetch instructions from the predicted path. A correct prediction maintains pipeline flow, but a misprediction forces a complete pipeline flush and restart, a penalty that increases with pipeline depth. Researchers have spent decades on branch prediction design to increase prediction accuracy. State-of-the-art hardware predictors are typically TAGE-like [39, 36, 37, 38], perceptron-based [16, 18], or a combination of those [17, 38]. Both types of predictors have distinct advantages: TAGE exploits the limited predictor storage very efficiently, whereas perceptron-based predictors can easily combine different sorts of input information. Recent researchers leverage PGO to increase prediction accuracy [20, 41, 46]. However, achieving high prediction accuracy often trades off with high space area on the chip. Plus, redesigning hardware to accommodate new compiler hints is non-scalable as it requires specialized ISA to accommodate software hints, hindering realistic in-production deployment.

If-conversion is a well-established compiler technique that eliminates branches by converting control-flow into data flow [3, 27, 4, 30, 2, 21]. The goal is to eliminate control dependencies that can limit the exposure of instruction-level parallelism (ILP) and avoid performance penalties from branch mispredictions. Instead of a conditional jump, the compiler generates a single, straight-line sequence of predicated instructions. The transformation is crucial for enabling other optimizations like vectorization and software pipelining, and it is especially critical for specialized architectures, such as digital signal processors (DSPs). Newest research applies the conversion early [27] to prevent the compiler from making optimizations that would harm performance. On architectures like ARM, this uses predicates to conditionally commit instruction results. The hardware executes these instructions, but only allows the results to be committed if their governing predicate is true; otherwise, the instruction is nullified.

However, x86 lacks hardware predication. If-conversion must instead execute both paths unconditionally and select the result with cmov, which requires both paths to be free of faulting operations. The compiler therefore skips branches containing memory operations, leaving numerous potentially optimizable code regions untransformed. Secondly, if-conversion transforms naively: it must fully execute both paths before selection. This “execute everything, select results after” model can introduce excessive instruction overhead, especially for branches with large bodies, often degrading performance despite eliminating mispredictions. To mitigate this, various approaches have been proposed, such as using PGO to selectively apply the transformation [47, 44]. Other hybrid techniques, like Wish Branches [21], defer the decision to runtime by encoding both the branch and its if-converted version in the binary. Despite these mitigations, the inefficient full-speculation model is largely retained. In contrast, MERIT moves beyond this branch-level decision by operating at the IR instruction level, melding similar operations to reduce redundant work rather than fully speculating both paths.

The Smith-Waterman algorithm [40], originally developed for biological sequence alignment, uses dynamic programming to find optimal local alignments between two sequences. Given two sequences of lengths $n$ and $m$, the algorithm constructs an $(n+1)\times (m+1)$ scoring matrix $M$ where $M[i,j]$ represents the optimal alignment score for the prefixes of length $i$ and $j$. The recurrence relation is:

where the score function returns a positive bonus for matching elements and zero (or a penalty) for mismatches. The gap penalty discourages unaligned elements. After computing $M$, backtracking from the maximum score yields the optimal local alignment that maximizes similarity while minimizing gaps.

MERIT applies the Smith-Waterman algorithm to align structurally similar instruction sequences across divergent control-flow paths. In this setting, the two sequences are the instruction lists $I_t$ and $I_f$ from the true and false branches, respectively. The score function returns a positive bonus (match_bonus) if two instructions form a compatible pair (Definition 1), and zero otherwise. Each gap corresponds to an instruction present in only one path, which necessitates an extraneous instruction insertion during the melding step. The resulting alignment score is subsequently used as a profitability filter (Section 4.4) to decide whether to proceed with the transformation.

The primary intuition behind MERIT transformation is to insert extraneous (i.e., dummy) instructions so that both divergent paths execute the same sequence of operations, enabling the explicit branch to be eliminated. Consider the function to_upper in Listing 1 ¹¹1Only for illustration purposes. Standard compiler optimizations apply after MERIT’s transformation., which converts all lowercase letters in a given string of length SIZE to uppercase ones. The if-conditional within the for-loop is executed repeatedly while iterating through each character of the string. This branch is highly unpredictable because of its data dependency on the characters of the input string. Experimenting to_upper on x86 shows that around 27% of all dynamic branches in the function are mispredicted and it leads to an extremely low IPC of 0.48.

The function to_upper_branchless is semantically the same as to_upper. However, the if-statement within the loop is eliminated, and the loop body is straight line code without any branches (here the ternary operator would be translated to cmov instructions in x86 assembly). This version has nearly zero branch mispredictions and yields a $32\times$ speedup compared to the original version. In this version, irrespective of the value cond, which holds a value representing the outcome of the branch in the original version, the computation of adding a constant value diff to the character of the string is executed. This does not affect the correctness, as when the branch is not taken, the transformation only adds a zero to the character. MERIT automatically recognizes the branched code and transforms it into the branchless version. However, traditional if-conversion does not perform this transformation.
Caveat: The illustrative str[i] += diff write in Listing 1 is not, in general, safe – it performs a store on the path where the original program did not. Section 4.3 shows that MERIT does not write to the original address in this case; instead, it uses safe address substitution so that the conditional store on the not-taken path targets a compiler-allocated SAFE_ADDR, which is non-aliasing with any program memory. The full transformed code (Figure 2(c)) makes this explicit with t4_t8 = cond ? &text[i] : SAFE_ADDR.

Figure 1 shows a case where both branches perform structurally identical computations differing only in their operands. On commodity architectures that rely on cmov (x86), if-conversion uses a speculative “compute everything, select results” method, calculates the outcomes for both the if and else paths entirely, and then uses (cmov) to select the correct final results. While this strategy eliminates branch misprediction penalties, due to the complete linearization on the control-flow, forcibly enabling if-conversion introduces excessive ALU instructions by performing every operation twice when only one outcome is needed. Plus, due to lack of hardware speculation support on x86, if-conversion does not transform code regions containing memory operations.

On the contrary, MERIT uses instruction-level alignment to recognize the structural similarity between the branches. Instead of duplicating the computations, it performs operand-level merging. This “select operands, compute once” method first uses select instructions to choose the correct constant based on the branch condition, and then executes each arithmetic operation a single time with the selected operand. MERIT achieves a significant reduction in total operations by merging the computation at the instruction level, rather than merely selecting between fully-computed results, leading to better performance.

The MERIT transformation adapts instruction melding from DARM [35], a GPU optimization that merges control-divergent paths. While DARM targets GPU warp divergence and tolerates partial merging, MERIT optimizes for x86 branch misprediction elimination with the following distinct requirements. First, complete branch elimination is paramount: partial merging that leaves residual branches defeats the purpose, as even a single remaining branch incurs the full misprediction penalty (15-17 cycles). Second, the transformation must minimize instruction overhead because excessive extraneous instructions or select chains create dependency bottlenecks that limit out-of-order execution. Third, memory speculation must be safe: speculative loads to invalid addresses are non-fatal on GPUs with forgiving memory models but catastrophic on x86 systems where page faults abort execution.

The key insight of MERIT is inserting extraneous instructions into both sides of a conditional branch such that the instruction sequences become identical, enabling complete alignment (formally defined in Section 4.2) and branch elimination. The transformation operates on diamond-shaped control-flow regions: if-then-else (two-sided) or if-then (one-sided) patterns where both paths converge to a common merge point.

Consider a program with an if-then-else branch with two basic blocks $B_t$ and $B_f$ (i.e., diamond-shaped control-flow), and $I_t$ and $I_f$ are the instruction sequences of those basic blocks, respectively.

If the instruction alignment for $B_t$ and $B_f$ is complete, we can fully merge $B_t$ and $B_f$ into a single basic block, eliminating the conditional branch. The first step of MERIT is to transform the alignment $A$ into a complete alignment $A^{\prime }$.

After computing the complete alignment $A^{\prime }$, MERIT generates the merged code by processing each aligned pair $(i_t,i_f)\in A^{\prime }$ according to the following rules:

Case 1: Identical operations and operands.

If $i_t$ and $i_f$ have the same operation and all operands match ($\forall k:{\text{operand}}_k(i_t)={\text{operand}}_k(i_f)$), emit a single instruction $i_{new}$ with no select. This is the ideal case requiring no additional overhead.

Case 2: Identical operations, differing operands.

If $i_t$ and $i_f$ have the same operation but operands differ, emit select instructions for each differing operand, then emit $i_{new}$ using the selected operands: $operan{d}_k^{\prime }=select(cond,operan{d}_k(i_t),operan{d}_k(i_f))$, $i_{new}=operation(operan{d}_1^{\prime },operan{d}_2^{\prime },\mathrm{\dots })$.

Case 3: Gaps (unaligned instructions).

If $(i_t,\psi )$ or $(\psi ,i_f)$ is a gap in the alignment, insert an extraneous instruction (Section 4.3) to complete the pair before applying Case 2.

Extraneous instructions are essential for completing the alignment when gaps exist. Their construction must ensure safety – no exceptions on either execution path.

While the Smith-Waterman algorithm (Section 2.3) computes the optimal alignment given two instruction sequences, not all alignments are profitable to transform. The alignment score is used as a profitability filter to decide whether to proceed with the transformation.

To quantify the similarity of def-use chains from both paths, MERIT computes:

Each matched pair contributes positively (shared computation that need only execute once), while each gap contributes negatively (an extraneous instruction that adds overhead). If the score falls below a threshold (default 0.2, exposed as a compilation flag), MERIT rejects the transformation. The threshold represents a trade-off: too high misses profitable opportunities; too low transforms branches where instruction overhead exceeds the misprediction savings.

Now we explain how MERIT transformation works in action using our running example (Listing 1). Figure 2 shows how to_upper function is transformed at each stage. Figure 2(a) shows to_upper function with an empty else section inserted. This is an extra canonicalization step of MERIT that converts if-then to if-then-else form, which allows it to merge if-then branches. Also, instructions are shown on separate lines (Lines 4-6) for better readability. Figure 2(b) shows the code after extraneous code insertion (Section 4.3). Here, the else path is empty; therefore, all the instructions are unaligned. The else path contains inserted extraneous instructions. For example, the load operation in Line 4 is repeated with a location (mem) from the safe global memory space in Line 9 after the extraneous code insertion. MERIT also tries to preserve def-use chains and minimize select operations required for merging. For example, variable t7 at Line 11 uses t6 at Line 10, similar to variable t3 using t2 as its first operand. t7 uses 0 as its second operand to avoid any overflow/underflow bugs. This example also demonstrates how store instructions are handled during extraneous code insertion. On the if path, there is a store (Line 7) of value t3 to text[i]. On the else path, the same store is performed (Line 12), but the stored location is mem (the safe address) and the stored value is t7. Figure 2(c) shows the code after the melding step (Section 4.2)²²2This sequence of steps is to illustrate the melding process. Standard optimizations (Constant propagation, DCE, CSE) run after MERIT to clean up redundant code.. Notice extra select instructions (shown as a ternary operator) are inserted to select operands if input operands do not match. The transformed program is much faster to execute than the original one (Section 3).

We describe the overall MERIT transformation for a program in Algorithm 1. MERIT transformation iterates through all the functions in a program. For each function, it collects all the valid branches for applying the MERIT transformation. The structural validity of a branch is determined by the two paths of the branch having straight-line control-flow converging at a basic block. In other words, control-flow regions of if-then-else (i.e., two-sided branches) or if-then (i.e., one-sided branches).

Then, for each valid branch, it computes the instruction alignment (Section 2.3). For two-sided branches, if the alignment score falls below the threshold (Section 4.4), the transformation is rejected. Otherwise, it inserts extraneous instructions to complete the alignment (Section 4.3) and merges the two blocks (Section 4.2). One-sided branches (if-then) bypass this threshold check, as discussed in Section 4.4. A whole basic block of extraneous instructions will be added. MERIT repeatedly performs these steps until there are no changes to the function. This is a fixed-point computation: each merge strictly decreases the number of eligible diamond regions in $F$ (the merged branch is eliminated, no new branches are introduced, and simplify(F) does not undo prior merges), so the outer Repeat loop terminates in at most a number of iterations linear in the original number of valid branches. Each merge may, however, expose new diamond regions (e.g., a nested branch becomes eligible after its enclosing branch is eliminated), which is precisely why iteration is required. As a defensive measure, our implementation additionally enforces a hard iteration cap.

The MERIT transformation satisfies two critical properties. First, semantic preservation: the transformed program produces identical outputs to the original program for all inputs. Second, crash-freedom: speculative execution does not trigger exceptions that the original program would avoid.

We implement MERIT as an LLVM pass in LLVM-14, integrated into the standard pipeline and enabled by default at optimization levels above -O0. It is scheduled after early canonicalization passes (e.g., SimplifyCFG, SROA, Mem2Reg) but before the inlining pipeline and later optimization stages. This position is intentional: early passes canonicalize the control-flow graph and eliminate redundant code, producing simpler IR that reduces the cost of MERIT’s instruction alignment. Running before inlining also keeps function bodies compact, limiting the number of branch sites MERIT must analyze per function. By running before backend optimizations, MERIT also avoids potential interference with later-stage alias analysis or memory layout changes.

While MERIT can achieve high performance by instruction-level merging on control-flow patterns, indiscriminately applying the transformation across all branches in a program can lead to poor performance. The overhead introduced by select instructions and operand multiplexing may exceed the benefit of branch elimination in cases where branch prediction accuracy is already high or when the merged instruction sequence is significantly longer than the original branching code. We address this challenge by enhancing the application of MERIT in the fashion of a Profile-guided Optimization (PGO): selectively transform based on observed empirical performance.

MERIT provides fine-grained filtering mechanisms accessible through compiler command-line options, either filtering by source file names, function names, or line numbers to enable selective application of the transformation. For instance, developers can specify function-level inclusion or exclusion lists using -include-func-names=func1,func2 to selectively enable MERIT only for high-value targets (e.g., hot functions, or functions whose branches have the highest misprediction rate), or -exclude-func-names=func3,func4 to blacklist problematic functions (e.g., functions known to cause heavy overhead). Additionally, MERIT supports file-level filtering via -exclude-file-names=utils.c,legacy.c to exclude entire source files, and line-level precision through -json-include-lines=profile.json where the JSON file maps source filenames to arrays of line numbers that should undergo transformation. This multi-granularity filtering infrastructure enables developers to iteratively refine their optimization strategy by excluding transformation sites that exhibit poor performance characteristics while retaining those that demonstrate clear benefits.

Table 1 reports compile-time overhead, number of transformed sites, and code-size changes for the -O2 baseline, if-conv, and MERIT. The baseline already performs a small amount of conservative branch simplification via SimplifyCFG (e.g., FoldTwoEntryPHINode); if-conv adds only a modest number of additional conversions (e.g., +48 on 500.perlbench_r), reflecting its conservativeness on x86 due to unsafe memory speculation. MERIT consistently discovers many more opportunities (e.g., 7175 vs. 1089 on 500.perlbench_r, and 3665 vs. 1144 on Python), enabled by IR-level analysis and safe transformation of conditional memory operations. Compile-time overhead tracks these site counts: if-conv stays within a few percent of baseline, while MERIT ranges from near-zero on small benchmarks up to 93.7% on 500.perlbench_r, where the $O(n^2)$ Smith-Waterman alignment cost is amplified by the 7175 transformation sites. In practice the cost is bounded by the branch-arm instruction count, which is typically small (median 15 instructions per arm on SPECrate), and selective application via PGO or a cost model (Section 7) keeps overhead manageable. Negative overheads in a few rows (e.g., $-11.3\%$ if-conv on 523.xalancbmk_r, $-10.8\%$ on 507.cactuBSSN_r) reflect downstream-pass speedups when branch elimination yields simpler IR for subsequent passes. Text-size changes remain small (typically $\le$2.5%), with the largest in this table being 5.1% (531.deepsjeng_r) and 4.2% (SQLite).

Our first case study, a MERIT-compiled SQLite engine running 22 TPC-H queries, clearly demonstrates the necessity of profile-guided selective transformation. For the TPC-H queries, which lack separate training datasets, we use the same inputs for both profiling and measurement. However, the function-level exclusion decisions generalize well across query shapes. For instance, excluding a poorly-performing hash table function benefits all queries that use that code path.

As shown in Figure 5, naively applying MERIT (blue bars) results in significant performance degradation on many queries, particularly 7, 8, 9, and 21, leading to a geomean of $0.85\times$. This is again due to the instruction overhead from transforming branches that were not performance bottlenecks.

However, the MERIT-PGO (green bars) results are transformative. By using PGO to identify and exclude problematic functions, we completely mitigate all slowdowns and achieve a positive geomean performance of $1.01\times$. Furthermore, MERIT-PGO achieves speedups on several queries (e.g., 5, 6, 11, 15, and 18) by targeting only the high-value, misprediction-prone branches. This selective transformation reinforces our takeaway: for complex real-world applications, MERIT must be paired with an intelligent cost model or PGO filtering to achieve performance gains. If-conversion barely affects performance, likely because it cannot transform the performance-critical blocks.

In our second case study, we evaluate MERIT on a large real-world application: the CPython interpreter (v3.10) with 40 benchmarks from the pyperformance suite [42]. Shown in Figure 6, applying MERIT indiscriminately results in a $1.01\times$ geomean speedup, with some workloads like unpickle_list (peak $1.11\times$) and nbody seeing benefits, while others do not. In comparison, the standard if-conv pass is more volatile, showing gains on some workloads (e.g., regex_effbot) but notable losses on others (e.g., tomli_loads, bpe_tokeniser, crypto_pyaes), for a $0.99\times$ geomean.

We do not report MERIT-PGO performance for the Python suite because its function-level filtering is too coarse-grained for a complex runtime like the interpreter, where diverse workloads from the pyperformance suite stress different parts of the code. Excluding a function to benefit one workload (e.g., nbody) could harm another (e.g., json_loads) that relies on the same function’s transformation. However, this points to a practical strategy for specialized environments: one could use MERIT with PGO to create a highly-tuned interpreter optimized only for their specific workload (e.g., a JSON serialization service), transforming only the hot, misprediction-prone functions on the application’s critical path to achieve speedups that would be washed out in a general-purpose benchmark.

MERIT is positioned before the inlining in the LLVM pipeline (Section 5) for three reasons, with the overarching principle that pre-inline placement bounds MERIT’s worst-case regressions while post-inline placement does not (substantiated quantitatively below). Note that in LLVM’s -O2 pipeline, the inliner does not run in isolation: it is flanked by SimplifyCFG invocations on both sides as part of the module-simplification cluster, so placing MERIT before or after the inliner places it before or after this whole cluster. First, transforming branches inside callees into straight-line code gives the inliner simpler, branchless function bodies to reason about, leading to better inlining decisions and cleaner input for downstream passes. Second, MERIT’s path-alignment step is quadratic in the instruction count of branch arms; post-inlining functions absorb many helpers, and the branch arms inside them are significantly larger, inflating alignment costs. Third, SimplifyCFG’s FoldTwoEntryPHINode fold collapses simple diamonds into select chains on its own and competes with MERIT for the same branches; running MERIT before the inliner-flanking SimplifyCFG invocations preserves diamond structures that would otherwise be folded away before MERIT could exploit them.

To quantify how these arguments play out in practice, we compare two placements: pre (MERIT before the inliner, the default used throughout the paper) and post (MERIT after the inliner). Both placements bypass the scoring filter of Section 4.4 so that only the pipeline position – not per-branch profitability decisions – drives the difference. This is why the geomeans reported below are lower than Section 6.3’s MERIT-O2 geomean of $1.42\times$, where the scoring filter selectively transforms only profitable branches. To probe the quadratic-alignment argument at realistic branch-arm sizes, we additionally measure compile time on the sqlite3.c amalgamation (8.9 MB single translation unit).

We first show the runtime performance of pre (geomean $1.17\times$) and post (geomean $1.16\times$) over the -O2 baseline on the 22 microbenchmarks in Figure 7. The two geomeans are essentially tied, but the per-benchmark distribution is not symmetric. Pre wins decisively on benchmarks whose callees contain divergent diamonds that the intermediate SimplifyCFG consumes before post ever sees them. smithw is the clearest case: pre runs before the inliner and merges all structurally-identical update branches inside the callee that is subsequently inlined, delivering a $1.30\times$ speedup, while post arrives after SimplifyCFG has already collapsed those branches into a select chain and regresses to $0.99\times$. dutchFlag shows the same pattern ($1.23\times$$\to$$1.00\times$). These two post-inline worst cases erase MERIT’s entire speedup on those workloads. Post, in turn, wins on benchmarks whose original branch arms were calls to structurally-similar helpers: the call-rejection filter of pre (Section 4.4) drops such branches unconditionally, whereas post sees two straight-line bodies after inlining and merges them. arrayUnion and arrayMerge exemplify this, gaining roughly $1.10\times$ under post versus near-baseline under pre. The asymmetry is what drives the placement decision: post’s wins cluster in a narrow $\sim$1.10$\times$ band, while its losses collapse speedups as large as $1.30\times$ all the way back to baseline.

Moving to compile-time (Table 2): pre adds 28% user-time and 4.1% peak resident set size (RSS, the compiler process’s peak memory footprint) for 2,328 merges, while post adds 51% user-time and 8.9% peak RSS for 2,716 merges. That is, post produces 17% more merges than pre, but at 23 percentage points more compile time and 4.8 percentage points more peak memory. The average branch arm post-inline is much larger than pre-inline because inlined helpers push additional instructions into each arm, and since MERIT’s path-alignment step is $O(n^2)$ in branch-arm instruction count, the cost is material at realistic branch-arm sizes.

Our evaluation demonstrates that forcibly applying MERIT transformation can degrade performance on complex workloads, especially when branches are mostly predictable (Section 6). This motivates the need for selective application. While MERIT-PGO addresses this limitation by using runtime profile data to filter transformations based on empirical performance, a more principled approach would use compile-time cost-benefit analysis to predict transformation profitability, specially for use cases where empirical performance data may not be readily available.

Such a cost model would need to balance the branch cost (misprediction probability and penalty) against the speculation overhead (instruction count, memory operations, critical path extension, asymmetry penalty). However, building an accurate static cost model faces fundamental challenges. First, estimating misprediction probability without runtime data is imprecise: real misprediction rates depend on input data patterns unknowable at compile time. Second, MERIT operates at the target-independent IR level, where hardware-specific factors such as execution port contention, store buffer capacity, and pipeline depth are not yet known. Third, the model would need to predict downstream backend interference (discussed below), requiring whole-pipeline cost analysis that remains an open research challenge.

Our evaluation further reveals additional complexities that a cost model must address. The imagick_r case study (Section 6) demonstrates that operation latency characteristics matter: floating-point operations impose significantly higher critical path extension than integer operations, causing per-iteration overhead to outweigh occasional misprediction savings. Similarly, memory operation patterns vary widely in their speculation cost: condition loads are essentially free, while different-base loads risk cache pollution. Understanding when these factors dominate the cost-benefit trade-off, and how they interact with workload characteristics (CPU-bound vs memory-bound), requires deeper analysis of microarchitectural behavior than simple instruction counting can provide.

Preliminary exploration of static cost modeling suggests that even sophisticated heuristics struggle to match PGO’s accuracy. This gap motivates continued reliance on profile-guided approaches for production deployment. Promising future directions include hybrid cost models that combine static analysis with runtime profiling, machine learning (TRACED [11]), or LLM Compiler [10], and that can learn complex cost patterns from large codebases, or adaptive systems that can dynamically adjust transformation decisions based on observed performance. However, the design space for such systems remains largely unexplored.

Orthogonal to the cost-model question, PGO integration itself can be automated end-to-end: the current function-level include/exclude lists are produced manually by the developer after inspecting profiles, but the same decisions can be derived automatically from LLVM’s standard profiling infrastructure (instrumentation or sample-based). Full automation (compile, instrument, run, derive per-function transform decisions, recompile) would remove the remaining developer burden and is the natural next deployment step.

The second limitation is the lack of coordination between MERIT and backend optimization passes. As quantified in Section 6.3, three backend interference patterns: select-to-branch reversion, loop unrolling amplification, and register pressure spills, can individually cause regressions of 4-41% even when the IR-level transformation successfully eliminates misprediction-prone branches. These patterns are not bugs in the backend; they arise because backend passes apply cost heuristics calibrated for branched code to MERIT’s branchless output, lacking awareness that the select chains originated from deliberate branch elimination rather than unoptimized source code.

A natural mitigation is to tag MERIT-generated select instructions with LLVM metadata that communicates transformation provenance to downstream passes. Concretely, MERIT can attach a !MERIT.select metadata node to every select it produces (e.g., number of merged instructions, whether the select guards a memory operation). Backend passes that currently revert selects to branches – notably code generator’s cmov-vs-branch lowering heuristic – can then query this metadata before applying their default cost model. When the metadata indicates that the select originated from MERIT’s deliberate branch elimination, these passes can either preserve the select unconditionally, or apply a threshold to partially reverse the MERIT transformation [5, 45], preventing the backend interferences that account for the regressions. The interaction between early IR-level transformations and late backend optimizations remains an important area for future compiler research.