Given this C code: int foo(int a, int b, int c, int d) { return a * b + c * d; } LLVM gives you a single total-ordering of all operations in t

Given this C code: int foo(int a, int b, int c, int d) { return a * b + c * d; } LLVM gives you a single total-ordering of all operations in this code, which makes it appear like computing %5 has to happen before %6, but in reality it doesn't - they could be swapped. define dso_local i32 @foo(i32 noundef %0, i32 noundef %1, i32 noundef %2, i32 noundef %3) local_unnamed_addr #0 !dbg !7 { %5 = mul nsw i32 %1, %0, !dbg !18 %6 = mul nsw i32 %3, %2, !dbg !19 %7 = add nsw i32 %6, %5, !dbg !20 ret i32 %7, !dbg !21 } Java's IRs instead tell you that %5 and %6 need to be computed before %7, but don't apply an ordering between them otherwise. They can do this because they use a graph of instructions, not a linear list of instructions. https://chrisseaton.com/truffleruby/basic-graal-graphs/ https://chrisseaton.com/truffleruby/basic-graal-graphs/