[Info-vax] LLVM, volatile and async VMS I/O and system calls

[chris]

On 10/03/21 10:21, Jan-Erik Söderholm wrote:
> Den 2021-10-03 kl. 01:06, skrev chris:
>>
>> So, it really comes down to optimiser choice of instruction, depending
>> on the use of the volatile keyword. Perhaps optimisers might optimise
>> such reads out, but that common ?.
>
> Optimizing out code not needed is one of the most common things that
> optimizers does. A very short example.
>
> int a;
> int b;
> void main() {
> a = 10;
> b = a;
> b = a;
> }
>
> The second assignment to b will simply be removed since it is
> a duplicate of the first and the value of a has not changed, at
> least not as far as the compiler can see.
>
> Compare with:
>
> int volatile a;
> int b;
> void main() {
> a = 10;
> b = a;
> b = a;
> }
>
> This tells the compiler that the value of a can change outside of
> the current compile unit and both assignments will be left to be
> done and the value of b could be different after each assignment.
>
> The first generates 7 Alpha instructions and the second 9 instructions.

Would be interesting to see instructions generated, so we can see what
is happening. Instruction count alone doesn't say much.

>
> Now, this was a very simple example, and a would probably point to some
> common area in memory shared by multiple processes, or to some hardware
> register that is changed outside of any code on the system. Or, as in the
> example from Simon, a buffer that is written to by the I/O sub-system.
>
> And no, I do not think that you are trolling, I think that you simply
> do not understand what Simon is trying to say. Either just some simple
> misunderstanding, or maybe you just to not understand the concept
> of "volatile" in this context.
>

Haven't seen that sort of result in optimisation here, but perhaps
i've not been paying attention. Just how common is it to optimise to
a register read only, rather than going back out to memory, which
seems to be the crux of this discussion ?...

Chris