ULP RISCV SPI Simulation Using Bit-banging

[MicroController]

- you can see why it might be timid[1] that end isn't changing as it's actually pointing to approximately itself.

No. With end (and ptr) being local variables they're not even supposed to be in RAM, much less somewhere near the (global) array they point to (i.o.w.: a local variable which address is never taken needs no consideration w.r.t. aliasing); besides, end is defined as const so the compiler has every right to assume that end will not change. Plus, if it couldn't prove that end won't change, the compiler would not be able to 'optimize' the loop back into an indexed for loop because it could not determine the number of iterations in advance.

[RandomInternetGuy]

I agree with your point on end not changing. I outsmarted myself writing the example to prove the point. Oops.

I disagree with your assumption that a local without its address taken HAS to be in a register and not potentially spilled to the stack. Maybe your point was that because it's on the stack, it can be more confident that it's not adjacent to the buffer being changed. That may be true in the latest generation of complier tech as my internals knowledge of such things is from far ago, but alias analysis and "knowing" that. Different stores would be in different segments were not able to look through the address of the stores when I was working on them. The state of the art (which I didn't capture fully here) around the turn of the century (I'm old) was to know that a store was happening somewhere and just not risk it. I'd agree in this simplistic example, it probably could divine that, but the more common cases were things like calling funtions that it couldn't prove were pure or that could potentially modify the (non+trivial) loop controls and such. A store through a pointer the was considered like a gunshot in the sky - we couldn't be sure where it could come down, so we just tried to avoid being there when it did.

So I failed in my example, but my overall point still stands, I think. Once it can't see the flow analysis and store graphs, the optimizer is more restricted in what it can do than if the controls and everything in the loop are straightforward indexed accesses where it can be known that non-obvious things like loop controls aren't being modified.

Simple takeaway for those that car about such things: For simple array traversal that may change members of the array, prefer array notation over changing pointers and referencing through those. Disassemble and verify if it matters.

Thank you for challenging that. We've made it clearer, I think.

[MicroController]

I disagree with your assumption that a local without its address taken HAS to be in a register and not potentially spilled to the stack.

That's not what I said. The point is that there's no 'legal' (or reproducible) way for a C program to alias a local variable without taking its address (unions aside); that's why

a local variable which address is never taken needs no consideration w.r.t. aliasing

and hence the compiler/optimizer is perfectly allowed to assume the variable's value does not change except when there's an explicit assignment to that variable. Anything else would basically be the definition of "UB".