Optimizations not applied when separate variables are used

[spease]

I noticed a case from this thread where the optimizations applied by the compiler are determined by the presence or absence of intermediate variables

fn main() {
    let a = [100u8; 1024];
    let b = [200u8; 1024];
    let c = a.iter().zip(b.iter()).map(|(ai, bi)| ai.saturating_add(*bi)).sum::<u8>();
    println!("c: {:?}", c);
}

fn main() {
    let c = [100u8; 1024].iter().zip([200u8; 1024].iter()).map(|(ai, bi)| ai.saturating_add(*bi)).sum::<u8>();
    println!("c: {:?}", c);
}

Looking at the assembly in the first case, it's clearly generating the two arrays separately.

	movl	$100, %esi
	movl	$1024, %edx
	callq	memset@PLT
	leaq	1096(%rsp), %rdi
	movl	$200, %esi
	movl	$1024, %edx
	callq	memset@PLT

In the second case, it does not appear to generate the arrays.

This is a little bit surprising to me and seems a bit undesirable since this means that making code more readable by storing intermediate operations in variables could lead to optimizations not being applied.

[andjo403]

if you replace the a and b variables with constants you get the same samme assembly.
https://godbolt.org/g/xFGvvZ

[andjo403]

similar to #36001

[arthurprs]

Potentially related to #41160

[spease]

@andjo403: Good to know, but I'd still tend to consider it unnecessarily unoptimized unless there's a good reason. Supposing even if they were mut, if the final value was identical for all inputs to the function, I'd hope that the compiler would be able to automatically reduce and simplify it.

For vec! I'd be a bit more on the fence since the implementation is expected to allocate on the heap, which could be seen as a side effect, though even then I probably wouldn't blame the compiler for optimizing it out if it could.

For the sort of use cases where mandating that something is actually allocated (probably cases where you are doing very low level sort of work) I'd think it'd be better to "opt-in" to deoptimization with a compiler attribute. People worrying a lot about the exact state of the stack will be more likely to recognize the need for such an attribute, and will likely want more explicit control over the optimizations applied anyway.

[oli-obk]

Closing as a duplicate of #36001