Unfortunately LLVM currently seems to have problem generating optimal code: if array size is raised to 64, then foo will still generate code that does some compute and eventually return true (because LLVM can't fold is_zero despite constant input).

I tried another coding style

#[inline(always)]
fn is_definitely_zero2<const N: usize>(x: &[u8; N]) -> bool {
    let zero = is_zero(x);
    if optimized_to_const(&zero) {
        zero
    } else {
        false
    }
}

This works similarly if size is 32, but if size is 64, then in this case it's even worse: both foo and baz will generate code now that does all compute and unconditionally return false. Run opt on the generated & optimized LLVM assembly for the second time will remove all the unwanted computation and replace with a single false return, though.

If it has already been folded to a const at that point, could it be turned into a const fn returning the value as const?

I meant would something like this be possible?

const fn precompute(x: u64) -> Option<u32> {
   return match x {
     1 => // special case
     2 => // special case
     _ => None
   }
}



fn foo(x: u64)  -> u32 {
   let precomputed = const { precompute(optimized_or_default(&x, u64::MAX)) }
   // magic happens here -------------------------------------^
   if let Some(p) = precomputed {
      return p;
   }
   // runtime impl 
}

Actually, thinking about it, this looks a lot like const_eval_select, except that it would also apply to const-optimizations in non-const contexts?

☔ The latest upstream changes (presumably #99420) made this pull request unmergeable. Please resolve the merge conflicts.

Closing this as it has been inactive for a long time. Feel free to open a new pr if required