Re: [PATCH bpf-next] bpf: abstract loop unrolling pragmas in BPF selftests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2/8/24 8:51 AM, Jose E. Marchesi wrote:
On Thu, 2024-02-08 at 16:35 +0100, Jose E. Marchesi wrote:
[...]

If the compiler generates assembly code the same code for profile2.c for
before and after, that means that the loop does _not_ get unrolled when
profiler.inc.h is built with -O2 but without #pragma unroll.

But what if #pragma unroll is used?  If it unrolls then, that would mean
that the pragma does something more than -funroll-loops/-O2.

Sorry if I am not making sense.  Stuff like this confuses me to no end
;)
Sorry, I messed up while switching branches :(
Here are the correct stats:

| File            | insn # | insn # |
|                 | before |  after |
|-----------------+--------+--------|
| profiler1.bpf.o |  16716 |   4813 |
This means:

- With both `#pragma unroll' and -O2 we get 16716 instructions.
- Without `#pragma unroll' and with -O2 we get 4813 instructions.

Weird.

Thanks for the analysis. I can reproduce with vs. without '#pragma unroll' at -O2
level, the number of generated insns is indeed different, quite dramatically
as the above numbers. I will do some checking in compiler.


| profiler2.bpf.o |   2088 |   2050 |
- Without `#pragma unroll' and with -O2 we get 2088 instructions.
- With `#pragma loop unroll(disable)' and with -O2 we get 2050
   instructions.

Also surprising.

| profiler3.bpf.o |   4465 |   1690 |




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux