From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: bpf@vger.kernel.org
Cc: cupertino.miranda@oracle.com, david.faust@oracle.com
Subject: CO-RE builtins purity and other compiler optimizations
Date: Wed, 05 Jul 2023 20:07:25 +0200 [thread overview]
Message-ID: <87zg4as04i.fsf@oracle.com> (raw)
Hello BPF people!
We are still working in supporting the pending CO-RE built-ins in GCC.
The trick of hooking in the parser to avoid constant folding, as
discussed during LSFMMBPF, seems to work well. Almost there!
So, most of the CO-RE associated C built-ins have the side effect of
emiting a CO-RE relocation in the .BTF.ext section. This is for example
the case of __builtin_preserve_enum_value.
Like calls to regular functions, calls to C built-ins are also
candidates to certain optimizations. For example, given this code:
: int a = __builtin_preserve_enum_value(*(typeof(enum E) *)eB, BPF_ENUMVAL_VALUE);
: int b = __builtin_preserve_enum_value(*(typeof(enum E) *)eB, BPF_ENUMVAL_VALUE);
The compiler may very well decide to optimize out the second call to the
built-in if it is to be considered "pure", i.e. given exactly the same
arguments it produces the same results.
We observed that clang indeed seems to optimize that way. See
https://godbolt.org/z/zqe9Kfrrj.
That kind of optimizations have an impact on the number of CO-RE
relocations emitted.
Question:
Is the BPF loader, the BPF verifier or any other core component sensible
in any way to the number (and ordering) of CO-RE relocations for some
given BPF C program? i.e. compiling the same BPF C program above with
and without that optimization, will it work in both cases?
If no, then perfect! Different compilers can optimize slightly
differently (or not optimize at all) and we can mark these built-ins as
pure in GCC as well, benefiting from optimizations without worrying to
have to emit exactly what clang emits.
If yes, wouldn't it be better to disable that kind of optimization in
all C BPF compilers, i.e. to make the compilers aware of the side-effect
so they will not optimize built-in calls out (or replicate them.) and to
make this mandatory in the CO-RE spec? Making a compiler to optimize
exactly like another compiler is difficult and sometimes even not
feasible.
Thanks in advance for the clarification/info!
next reply other threads:[~2023-07-05 18:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 18:07 Jose E. Marchesi [this message]
2023-07-06 0:02 ` CO-RE builtins purity and other compiler optimizations Andrii Nakryiko
2023-07-06 5:57 ` Yonghong Song
2023-07-06 9:03 ` Jose E. Marchesi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zg4as04i.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=cupertino.miranda@oracle.com \
--cc=david.faust@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox