Inconsistent iterator optimization

[bugadani]

I'm not sure if this is the fault of const propagation (probably not?), but these examples (more examples, but a lot more messy) result in unexpected code.

In some instances, the function bodies are evaluated and are replaced by a constant value as expected. However, given some usage patterns, (the most simple is an extra iterator.next call where the return value is ignored) this simplification does not happen. It's not clear why some patterns can be simplified and others can't.

[tesuji]

Please come up with minimal example to show what you mean about missed-optimization.
The code in godbolt link you show look to be optimized OK. No surprise to me.

[bugadani]

All right, highlighted 2 from that mess: https://rust.godbolt.org/z/EjW13c

In this case, by optimized I mean evaluated.

One sums the array, other sums every second element.

I'm trying to figure out why this happens, but as of yet I have no idea why/where the first function gets interpreted... It's obvious it's not during mir optimization, since the emitted mir is rather verbose.

[tesuji]

This seems like a duplicate of #73825 .
In short, if you use let s = &[1, 2, 3, 4, 5, 6, 7]; (note the borrow "&"), both function should be optimized.

[tesuji]

why the first function gets interpreted ?

maybe const prop in LLVM after inlining.

[bugadani]

Thanks for the info. So if I make the arrays const, their respective functions get evaluated. So the int-array cases are a duplicate of #73825 and the string cases are duplicate of #75618

[bugadani]

Although, to be fair, it's still not clear why an extra iterator.next messes things up.

[tesuji]

This is the thing I don't know. After comparing the MIR with and without "&",
"&[1, 2, 3, 4, 5, 6, 7]" is promoted while plain array isn't.