From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jiong Wang <jiong.wang@netronome.com>
Cc: daniel@iogearbox.net, bpf@vger.kernel.org,
netdev@vger.kernel.org, oss-drivers@netronome.com
Subject: Re: [PATCH/RFC bpf-next 04/16] bpf: mark sub-register writes that really need zero extension to high bits
Date: Wed, 27 Mar 2019 09:50:58 -0700 [thread overview]
Message-ID: <20190327165057.mzk52t5wedtyf7fl@ast-mbp> (raw)
In-Reply-To: <1553623539-15474-5-git-send-email-jiong.wang@netronome.com>
On Tue, Mar 26, 2019 at 06:05:27PM +0000, Jiong Wang wrote:
> eBPF ISA specification requires high 32-bit cleared when low 32-bit
> sub-register is written. This applies to destination register of ALU32 etc.
> JIT back-ends must guarantee this semantic when doing code-gen.
>
> x86-64 and arm64 ISA has the same semantic, so the corresponding JIT
> back-end doesn't need to do extra work. However, 32-bit arches (arm, nfp
> etc.) and some other 64-bit arches (powerpc, sparc etc), need explicit zero
> extension sequence to meet such semantic.
>
> This is important, because for code the following:
>
> u64_value = (u64) u32_value
> ... other uses of u64_value
>
> compiler could exploit the semantic described above and save those zero
> extensions for extending u32_value to u64_value. Hardware, runtime, or BPF
> JIT back-ends, are responsible for guaranteeing this. Some benchmarks show
> ~40% sub-register writes out of total insns, meaning ~40% extra code-gen (
> could go up to more for some arches which requires two shifts for zero
> extension) because JIT back-end needs to do extra code-gen for all such
> instructions.
>
> However this is not always necessary in case u32_value is never cast into
> a u64, which is quite normal in real life program. So, it would be really
> good if we could identify those places where such type cast happened, and
> only do zero extensions for them, not for the others. This could save a lot
> of BPF code-gen.
>
> Algo:
> - Record indices of instructions that do sub-register def (write). And
> these indices need to stay with function state so path pruning and bpf
> to bpf function call could be handled properly.
>
> These indices are kept up to date while doing insn walk.
>
> - A full register read on an active sub-register def marks the def insn as
> needing zero extension on dst register.
>
> - A new sub-register write overrides the old one.
>
> A new full register write makes the register free of zero extension on
> dst register.
>
> - When propagating register read64 during path pruning, it also marks def
> insns whose defs are hanging active sub-register, if there is any read64
> from shown from the equal state.
>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
> ---
> include/linux/bpf_verifier.h | 4 +++
> kernel/bpf/verifier.c | 85 +++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 27761ab..0ae9a3f 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -181,6 +181,9 @@ struct bpf_func_state {
> */
> u32 subprogno;
>
> + /* tracks subreg definition. */
> + s32 subreg_def[MAX_BPF_REG];
Same comment as Ed and another question: why it's not part of bpf_reg_state ?
next prev parent reply other threads:[~2019-03-27 16:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 18:05 [PATCH/RFC bpf-next 00/16] bpf: eliminate zero extensions for sub-register writes Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 01/16] bpf: turn "enum bpf_reg_liveness" into bit representation Jiong Wang
2019-03-27 15:44 ` Alexei Starovoitov
2019-03-26 18:05 ` [PATCH/RFC bpf-next 02/16] bpf: refactor propagate_live implementation Jiong Wang
2019-03-26 18:26 ` Jann Horn
2019-03-26 19:45 ` Jiong Wang
2019-03-27 16:35 ` Alexei Starovoitov
2019-03-27 16:44 ` Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 03/16] bpf: split read liveness into REG_LIVE_READ64 and REG_LIVE_READ32 Jiong Wang
2019-03-26 20:21 ` Jann Horn
2019-03-26 20:50 ` Jiong Wang
2019-03-27 16:38 ` Alexei Starovoitov
2019-03-26 18:05 ` [PATCH/RFC bpf-next 04/16] bpf: mark sub-register writes that really need zero extension to high bits Jiong Wang
2019-03-26 18:44 ` Edward Cree
2019-03-26 19:47 ` Jiong Wang
2019-04-05 20:44 ` Jiong Wang
2019-04-06 3:41 ` Alexei Starovoitov
2019-04-06 6:56 ` Jiong Wang
2019-04-07 2:51 ` Alexei Starovoitov
2019-03-27 16:50 ` Alexei Starovoitov [this message]
2019-03-27 17:06 ` Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 05/16] bpf: reduce false alarm by refining "enum bpf_arg_type" Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 06/16] bpf: new sysctl "bpf_jit_32bit_opt" Jiong Wang
2019-03-27 17:00 ` Alexei Starovoitov
2019-03-27 17:06 ` Jiong Wang
2019-03-27 17:17 ` Alexei Starovoitov
2019-03-27 17:18 ` Jiong Wang
2019-03-27 17:45 ` Alexei Starovoitov
2019-03-27 19:13 ` Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 07/16] bpf: insert explicit zero extension instructions when bpf_jit_32bit_opt is true Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 08/16] arm: bpf: eliminate zero extension code-gen Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 09/16] powerpc: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 10/16] s390: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 11/16] sparc: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 12/16] x32: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 13/16] riscv: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 14/16] nfp: " Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 15/16] selftests: bpf: new field "xlated_insns" for insn scan test after verification Jiong Wang
2019-03-26 18:05 ` [PATCH/RFC bpf-next 16/16] selftests: bpf: unit testcases for zero extension insertion pass Jiong Wang
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=20190327165057.mzk52t5wedtyf7fl@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jiong.wang@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.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