All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: alexei.starovoitov@gmail.com
Cc: sparclinux@vger.kernel.org, netdev@vger.kernel.org,
	ast@kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH RFC] sparc64: eBPF JIT
Date: Tue, 18 Apr 2017 22:27:03 -0400 (EDT)	[thread overview]
Message-ID: <20170418.222703.574792250384665834.davem@davemloft.net> (raw)
In-Reply-To: <20170418225707.GA65449@ast-mbp.thefacebook.com>

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 18 Apr 2017 15:57:09 -0700

> On Tue, Apr 18, 2017 at 02:37:32PM -0400, David Miller wrote:
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Date: Mon, 17 Apr 2017 22:44:47 -0700
>> 
>> > The way llvm generates stack access is:
>> > rX = r10
>> > rX += imm
>> > and that's the only thing verifier recognizes as valid ptr_to_stack.
>> > Like rX -= imm will not be recognized as proper stack offset,
>> > since llvm never does it.
>> 
>> That simplifies things significantly for me.
>> 
>> I only allow moves from the frame pointer to another register,
>> and when I see that I rewrite it to "add FP, STACK_BIAS, DST_REG"
> 
> Sounds good to me. Alternative idea: can the above
> 'add FP, STACK_BIAS, one_of_local_regs' be done once in prologue
> and that register used as substitue for R10 ?
> (assuming non-leaf function)
> I completely forgot by now how 2047 magic works.

Well, I'm trying to understand what that would buy us.

If I'm always going to see that kind of sequence:

	rX = r10
	rx += offset

then I always have that "r10" move available to deal with the bias.
It comes for free.

Right now the current version of the sparc64 JIT will emit:

	add	%fp, 2047, bpf2sparc[rX]
	add	bpf2sparc[rX], offset, bpf2sparc[rX]

for that BPF sequence.

Anyways, thanks to your and Daniel's feedback I'm very confident
with the code now.  All that's really left is tail calls, and I'll
set up a BPF compilation and test environment for that.

WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
To: alexei.starovoitov@gmail.com
Cc: sparclinux@vger.kernel.org, netdev@vger.kernel.org,
	ast@kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH RFC] sparc64: eBPF JIT
Date: Wed, 19 Apr 2017 02:27:03 +0000	[thread overview]
Message-ID: <20170418.222703.574792250384665834.davem@davemloft.net> (raw)
In-Reply-To: <20170418225707.GA65449@ast-mbp.thefacebook.com>

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 18 Apr 2017 15:57:09 -0700

> On Tue, Apr 18, 2017 at 02:37:32PM -0400, David Miller wrote:
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Date: Mon, 17 Apr 2017 22:44:47 -0700
>> 
>> > The way llvm generates stack access is:
>> > rX = r10
>> > rX += imm
>> > and that's the only thing verifier recognizes as valid ptr_to_stack.
>> > Like rX -= imm will not be recognized as proper stack offset,
>> > since llvm never does it.
>> 
>> That simplifies things significantly for me.
>> 
>> I only allow moves from the frame pointer to another register,
>> and when I see that I rewrite it to "add FP, STACK_BIAS, DST_REG"
> 
> Sounds good to me. Alternative idea: can the above
> 'add FP, STACK_BIAS, one_of_local_regs' be done once in prologue
> and that register used as substitue for R10 ?
> (assuming non-leaf function)
> I completely forgot by now how 2047 magic works.

Well, I'm trying to understand what that would buy us.

If I'm always going to see that kind of sequence:

	rX = r10
	rx += offset

then I always have that "r10" move available to deal with the bias.
It comes for free.

Right now the current version of the sparc64 JIT will emit:

	add	%fp, 2047, bpf2sparc[rX]
	add	bpf2sparc[rX], offset, bpf2sparc[rX]

for that BPF sequence.

Anyways, thanks to your and Daniel's feedback I'm very confident
with the code now.  All that's really left is tail calls, and I'll
set up a BPF compilation and test environment for that.

  reply	other threads:[~2017-04-19  2:27 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-17  3:38 [PATCH RFC] sparc64: eBPF JIT David Miller
2017-04-17  3:38 ` David Miller
2017-04-17 18:44 ` Daniel Borkmann
2017-04-17 18:44   ` Daniel Borkmann
2017-04-17 19:03   ` David Miller
2017-04-17 19:03     ` David Miller
2017-04-17 20:55     ` Daniel Borkmann
2017-04-17 20:55       ` Daniel Borkmann
2017-04-17 20:12   ` David Miller
2017-04-17 20:12     ` David Miller
2017-04-21 16:46   ` David Miller
2017-04-21 16:46     ` David Miller
2017-04-21 16:50     ` Daniel Borkmann
2017-04-21 16:50       ` Daniel Borkmann
2017-04-21 18:49     ` Alexei Starovoitov
2017-04-21 18:49       ` Alexei Starovoitov
2017-04-21 19:02       ` David Miller
2017-04-21 19:02         ` David Miller
2017-04-21 19:26         ` Alexei Starovoitov
2017-04-21 19:26           ` Alexei Starovoitov
2017-04-21 19:41           ` David Miller
2017-04-21 19:41             ` David Miller
2017-04-17 23:27 ` Alexei Starovoitov
2017-04-17 23:27   ` Alexei Starovoitov
2017-04-18  1:12   ` David Miller
2017-04-18  1:12     ` David Miller
2017-04-18  5:44     ` Alexei Starovoitov
2017-04-18  5:44       ` Alexei Starovoitov
2017-04-18 18:37       ` David Miller
2017-04-18 18:37         ` David Miller
2017-04-18 22:57         ` Alexei Starovoitov
2017-04-18 22:57           ` Alexei Starovoitov
2017-04-19  2:27           ` David Miller [this message]
2017-04-19  2:27             ` David Miller
2017-04-22  1:19           ` David Miller
2017-04-22  1:19             ` David Miller

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=20170418.222703.574792250384665834.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.