RFR: 8263718: unused-result warning happens at os_linux.cpp

[David Holmes]

On 19/03/2021 4:08 pm, David Holmes wrote:
> On 19/03/2021 3:56 pm, Thomas Stüfe wrote:
>>      > It has also been raised (as it was here) whether the alloca is
>>     even left
>>      > in place by the compiler. Something I have yet to check.
>>
>>              call    _ZN6Thread26record_stack_base_and_sizeEv at PLT
>>     .LVL2492:
>>              .loc 3 666 3 is_stmt 1 view .LVU7882
>>              .loc 3 667 3 view .LVU7883
>>     .LBB6399:
>>     .LBI6399:
>>              .loc 3 1359 5 view .LVU7884
>>     .LBB6400:
>>              .loc 3 1360 3 view .LVU7885
>>              .loc 3 1360 18 is_stmt 0 view .LVU7886
>>              call    getpid at PLT
>>     .LVL2493:
>>     .LBE6400:
>>     .LBE6399:
>>              .loc 3 668 3 is_stmt 1 view .LVU7887
>>              .loc 3 670 36 is_stmt 0 view .LVU7888
>>              movq    %r13, %rdi
>>              .loc 3 668 3 view .LVU7889
>>              addl    $1, _ZZL19thread_native_entryP6ThreadE7counter(%rip)
>>              .loc 3 670 3 is_stmt 1 view .LVU7890
>>              .loc 3 670 36 is_stmt 0 view .LVU7891
>>              call    _ZN6Thread25initialize_thread_currentEv at PLT
>>
>>     Appears the alloca has been elided, along with the arithmetic.
>>
>>     Don't know if that is true for other platforms.
>>
>>     David
>>     -----
>>
>>
>> Which would explain why we don't see effects in benchmarks. Question 
>> is, do we repair this or remove it.
> 
> I'm trying a repair and re-running the benchmarks.
> 
> The repair is simply:
> 
> static void* _stack_pad = alloca(...);

That doesn't seem to work either:

         call    getpid at PLT
.LVL2493:
.LBE6400:
.LBE6399:
         .loc 3 668 3 is_stmt 1 view .LVU7887
         .loc 3 668 29 is_stmt 0 view .LVU7888
         movzbl  _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip), 
%eax
         testb   %al, %al
         je      .L2250
.L2214:
         .loc 3 670 3 is_stmt 1 view .LVU7889
         .loc 3 670 36 is_stmt 0 view .LVU7890
         movq    %r13, %rdi
         call    _ZN6Thread25initialize_thread_currentEv at PLT

and:

.L2250:
         .cfi_restore_state
         .loc 3 668 29 discriminator 1 view .LVU8015
         leaq    _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip), 
%rdi
         call    __cxa_guard_acquire at PLT
.LVL2520:
         testl   %eax, %eax
         je      .L2214
         .loc 3 668 29 discriminator 2 view .LVU8016
         leaq    _ZGVZL19thread_native_entryP6ThreadE10_stack_pad(%rip), 
%rdi
         addl    $1, _ZZL19thread_native_entryP6ThreadE7counter(%rip)
         call    __cxa_guard_release at PLT
.LVL2521:
         jmp     .L2214

I'm not really sure what that is doing but now even the counter++ has 
been elided, along with the calculation and the alloca. ??

Then I tried:

void* _stack_pad = alloca(((pid ^ counter++) & 7) * 128);
if (_stack_pad == 0) counter--;

and still no alloca:

         call    _ZN6Thread26record_stack_base_and_sizeEv at PLT
.LVL2492:
         .loc 3 666 3 is_stmt 1 view .LVU7882
         .loc 3 667 3 view .LVU7883
.LBB6399:
.LBI6399:
         .loc 3 1360 5 view .LVU7884
.LBB6400:
         .loc 3 1361 3 view .LVU7885
         .loc 3 1361 18 is_stmt 0 view .LVU7886
         call    getpid at PLT
.LVL2493:
.LBE6400:
.LBE6399:
         .loc 3 668 3 is_stmt 1 view .LVU7887
         .loc 3 671 36 is_stmt 0 view .LVU7888
         movq    %r13, %rdi
         .loc 3 668 22 view .LVU7889
         addl    $1, _ZZL19thread_native_entryP6ThreadE7counter(%rip)
         .loc 3 669 3 is_stmt 1 view .LVU7890
         .loc 3 671 3 view .LVU7891
         .loc 3 671 36 is_stmt 0 view .LVU7892
         call    _ZN6Thread25initialize_thread_currentEv at PLT

Have I missed something obvious here? (This is g++ -S output).

David
-----

>>      >> PR: https://git.openjdk.java.net/jdk/pull/3042
>>     <https://git.openjdk.java.net/jdk/pull/3042>
>>      >>
>>