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

[chris]

On 10/03/21 16:29, Bill Gunshannon wrote:
> On 10/3/21 11:16 AM, Jan-Erik Söderholm wrote:
>> Den 2021-10-03 kl. 16:21, skrev Bill Gunshannon:
>>> On 10/3/21 8:29 AM, chris wrote:
>>>> 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.
>>>
>>> More interesting than you might thnk.  Here's an x86 version.
>>>
>>>      .text
>>>      .globl    main
>>>      .type    main, @function
>>> main:
>>> .LFB0:
>>>      .cfi_startproc
>>>      movl    $10, a(%rip)
>>>      movl    $10, b(%rip)
>>>      ret
>>>      .cfi_endproc
>>> .LFE0:
>>>      .size    main, .-main
>>>      .comm    b,4,4
>>>      .comm    a,4,4
>>>      .ident    "GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0"
>>>      .section    .note.GNU-stack,"", at progbits
>>>
>>> ---------------------------------------
>>>
>>>      .text
>>>      .globl    main
>>>      .type    main, @function
>>> main:
>>> .LFB0:
>>>      .cfi_startproc
>>>      movl    $10, a(%rip)
>>>      movl    a(%rip), %eax
>>>      movl    a(%rip), %eax
>>>      movl    %eax, b(%rip)
>>>      ret
>>>      .cfi_endproc
>>> .LFE0:
>>>      .size    main, .-main
>>>      .comm    b,4,4
>>>      .comm    a,4,4
>>>      .ident    "GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0"
>>>      .section    .note.GNU-stack,"", at progbits
>>>
>>> ------------------------------------------
>>>
>>> And the diff:
>>>
>>> <     movl    $10, b(%rip)
>>> ---
>>> >     movl    a(%rip), %eax
>>> >     movl    a(%rip), %eax
>>> >     movl    %eax, b(%rip)
>>>
>>>
>>> Most interesting.
>>>
>>> bill
>>
>> OK. since b isn't used for anything between the two assignments,
>> the first movl is removed. But the final value is still frmo the
>> second read of a, anyway.
>>
>> Try with using b for something in between the assignments.
>>
>> int a;
>> int b;
>> int c, d;
>> void main() {
>>   a = 10;
>>   b = a;
>>   c = b;
>>   b = a;  (Probably removed by the optimizer...)
>>   d = b;
>> }
>>
>> int volatile a;
>> int b;
>> int c, d;
>> void main() {
>>   a = 10;
>>   b = a;
>>   c = b;
>>   b = a;
>>   d = b;
>> }
>>
>> Anyway, it is obvious that "volatile" does change the way the
>> compiler/optimizer builds the code. As expected, of course.
>>
>>
>
> I thought the funnier part was in the first one where the
> optimizer decided that moving a to b was not necessary and
> it merely assigned the constant value 10 to both of them.
>
> bill
>

Immediate adressing mode is usually faster the reg indirect,
or mode where the cpu has to evaluate an address expression...

Chris