Help is available by moving the cursor above any 
symbol or by checking MAQAO website.
[ 4 / 4 ] Application profile is long enough (80.20 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Architecture specific option -march=znver4 is used
[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % of the execution time)
To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code
[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (19.48%)
If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.
[ 4 / 4 ] Loop profile is not flat
At least one loop coverage is greater than 4% (19.44%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (19.47%)
If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.
[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations
It could be more efficient to inline by hand BLAS1 operations
[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.01%) lower than cumulative innermost loop coverage (19.47%)
Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex
[ 0 / 2 ] More than 10% (70.47%) is spend in Libm/SVML (special functions)
The application is heavily using special math functions (powers, exp, sin etc…) proper library version have to be used. Exact accuracy needs have to be evaluated. Perform input value profiling, first count how many different input values. Using AOCC you should link your application with the AMD math library with -lamdlibm -lm. To use the vector version of the library (and potentially enable vectorization of loops calling math functions)you also need to compile with the -fveclib=AMDLIBM option. If you wish to use the fastest version (may lower precision) you need to compile with -Ofast -fsclrlib=AMDLIBM and link with -lamdlibmfast -lamdlibm -lm options.
[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations
BLAS2 calls usually could make a poor cache usage and could benefit from inlining.
| Loop ID | Analysis | Penalty Score |
|---|---|---|
| ►Loop 3 - exec | Execution Time: 19 % - Vectorization Ratio: 2.35 % - Vector Length Use: 7.13 % | |
| ►Control Flow Issues | 3 | |
| ○ | [SA] Presence of calls - Inline either by compiler or by hand and use SVML for libm calls. There are 1 issues (= calls) costing 1 point each. | 1 |
| ○ | [SA] Several paths (2 paths) - Simplify control structure or force the compiler to use masked instructions. There are 2 issues ( = paths) costing 1 point each. | 2 |
| ►Data Access Issues | 4 | |
| ○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 1 issues ( = data accesses) costing 2 point each. | 2 |
| ○ | [SA] More than 20% of the loads are accessing the stack - Perform loop splitting to decrease pressure on registers. This issue costs 2 points. | 2 |
| ►Vectorization Roadblocks | 5 | |
| ○ | [SA] Presence of calls - Inline either by compiler or by hand and use SVML for libm calls. There are 1 issues (= calls) costing 1 point each. | 1 |
| ○ | [SA] Several paths (2 paths) - Simplify control structure or force the compiler to use masked instructions. There are 2 issues ( = paths) costing 1 point each. | 2 |
| ○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 1 issues ( = data accesses) costing 2 point each. | 2 |
| ►Inefficient Vectorization | 2 | |
| ○ | [SA] Inefficient vectorization: use of masked instructions - Simplify control structure. The issue costs 2 points. | 2 |
| ►Loop 1 - exec | Execution Time: 0 % - Vectorization Ratio: 25.00 % - Vector Length Use: 10.94 % | |
| ►Data Access Issues | 4 | |
| ○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 1 issues ( = data accesses) costing 2 point each. | 2 |
| ► | [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, SHUFFLE/PERM) - Simplify data access and try to get stride 1 access. There are 2 issues (= instructions) costing 1 point each. | 2 |
| ○ | Number of INSERT/EXTRACT instructions: 1 Number of XMM SHUFFLE/PERM instructions: 1 | |
| ►Vectorization Roadblocks | 2 | |
| ○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 1 issues ( = data accesses) costing 2 point each. | 2 |
| ►Inefficient Vectorization | 2 | |
| ► | [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, SHUFFLE/PERM) - Simplify data access and try to get stride 1 access. There are 2 issues (= instructions) costing 1 point each. | 2 |
| ○ | Number of INSERT/EXTRACT instructions: 1 Number of XMM SHUFFLE/PERM instructions: 1 |