[llvm-bugs] [Bug 46999] New: Unrolling loops leads to sub-optimal code generation in ARM Cortex A72

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46999

            Bug ID: 46999
           Summary: Unrolling loops leads to sub-optimal code generation
                    in ARM Cortex A72
           Product: clang
           Version: 10.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bhavana.kilambi at blackfigtech.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Created attachment 23816
  --> https://bugs.llvm.org/attachment.cgi?id=23816&action=edit
string copy source code

Summary: 
LLVM 10.0.0.1 unrolls two loops in a string copy function which leads to
unaligned memory access when -mcpu= cortex-a72 (ARM) option is specified during
compilation. When this option is not specified, the compiler does not unroll
the loops and the code gen does not contain any unaligned accesses.


Build options and other details for reproduction:
LLVM: clang version 10.0.0.1 
Arch : ARM cortex-a72
Optimization options used : -fno-builtin --target=arm64 -mcpu= cortex-a72
-ffixed-x18 -std=c11 -nostdlibinc -nostdinc++ -ftls-model=local-exec
-fno-builtin -fno-strict-aliasing -mno-implicit-float -O2 -w 
( The above list of build options have been added as they are specific to our
workload and are required to be used during compilation)


Source code and code gen : 
The source is a basic strncpy function and is attached in this bug. 
The following is the assembly generated when compiled with -mcpu=cortex-a72
option :

        .p2align        4
        .type   strncpy, at function
strncpy: 
        cbz     w2, .LBB0_10
        mov     x8, x0
.LBB0_2:                         
        ldrb    w9, [x1]
        cbz     w9, .LBB0_4
        add     x1, x1, #1    
        subs    w2, w2, #1 
        strb    w9, [x8], #1
        b.ne    .LBB0_2
        b       .LBB0_10
.LBB0_4:                   
        sub     w9, w2, #1
        tst     w2, #0x3
        b.eq    .LBB0_8
        mov     w10, wzr
        and     w11, w2, #0x3
.LBB0_6:                   
        strb    wzr, [x8], #1
        add     w10, w10, #1
        cmp     w11, w10
        b.ne    .LBB0_6
        sub     w2, w2, w10
.LBB0_8:                                
        cmp     w9, #3                  
        b.lo    .LBB0_10
.LBB0_9:                             
        subs    w2, w2, #4     
        str     wzr, [x8], #4
        b.ne    .LBB0_9
.LBB0_10:                           
        ret
.Lfunc_end0:
        .size   strncpy, .Lfunc_end0-strncpy 

>From the assembly sequence above, it can be noticed that there is a 4B store
“str wzr, [x8], #4” which could be to an unaligned memory location.


Without the -mcpu=cortex-a72 option the compiler generates the following
assembly sequence : 
.p2align        2
        .type   strncpy, at function
strncpy:     
        cbz     w2, .LBB0_5
        mov     x8, x0
.LBB0_2:                                
        ldrb    w9, [x1]
        cbz     w9, .LBB0_4
        add     x1, x1, #1              
        subs    w2, w2, #1           
        strb    w9, [x8], #1
        b.ne    .LBB0_2
        b       .LBB0_5
.LBB0_4:                              
        add     w9, w9, #1      
        cmp     w2, w9
        strb    wzr, [x8], #1
        b.ne    .LBB0_4
.LBB0_5:                         
        ret


Observations:
After some debugging with the unroll pass in LLVM, I notice that the
-mcpu=cortex-a72 option uses the model file for arm cortex A-57 which in turn
overrides some default values (for ARM generic) related to loop buffer.
       The case where the cortex-a72 option is not used, it uses the default
value for “LoopMicroOpBufferSize” (which is 0) in getUnrollingPreferences()
function in BasicTTIImpl.h. 
       With the -mcpu=cortex-a72 option, the value of "LoopMicroOpBufferSize"
is overridden by 16 because of which eventually in the function, the variable
"UP.Runtime" is set to True and the loop gets unrolled. As the value for
“LoopMicroOpBufferSize” is 0 for the case without the cortex-a72 option, it
returns control to the "LoopUnrollPass.cpp" where the default value for
"UP.Runtime" is False and hence the loop does not get unrolled. 


Possible Solution(s):
Disabling loop unrolling with the -mcpu=cortex-a72 option results in no
unrolling and the assembly resembles that of the case without this option.

However, we would like to know if some setting changes could be possible
regarding the default “LoopMicroOpBufferSize” for cortex-a72 specifically? Or
any other work around that can be done in the LLVM source instead of explicitly
using flags or other options?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200805/7665b789/attachment.html>