similar to: [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support

On Sat, Sep 23, 2017 at 1:41 AM, Jakub Kicinski via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > On Fri, 22 Sep 2017 22:03:47 -0700, Yonghong Song wrote: >> On 9/22/17 9:24 AM, Jakub Kicinski wrote: >> > On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote: >> >> On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:

On 09/18/2017 10:47 PM, Jiong Wang wrote: > Hi, > > Currently, LLVM eBPF backend always generate code in 64-bit mode, this may > cause troubles when JITing to 32-bit targets. > > For example, it is quite common for XDP eBPF program to access some packet > fields through base + offset that the default eBPF will generate BPF_ALU64 for > the address formation, later when

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessary shifts on x86_64 and improve the performance. Looking through a few bpf programs and it looks like the opportunity is not great, but still nice to have if we have this capability. As you

On Sat, Sep 23, 2017 at 10:41:25AM +0200, Jakub Kicinski wrote: > > > Thinking about next steps - do we expect the 32b operations to clear the > > > upper halves of the registers? The interpreter does it, and so does > > > x86. I don't think we can load 32bit-only programs on 64bit hosts, so > > > we would need some form of data flow analysis in the kernel

On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote: > On 06/15/2016 10:14 PM, Alexei Starovoitov wrote: >> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev >> <iovisor-dev at lists.iovisor.org> wrote: >>> This same value for EM_BPF is being propagated to glibc, >>> elfutils, and binutils. >> >> great! >> Can

Hi, Jiong, The new patch looks good. I did some basic testing on net-next:samples/bpf and net-next:tools/testing/selftests/bpf and it works fine. All existing llvm unit tests are not impacted as well as expected. I have applied the patch to the trunk. Besides your other work to support 32bit abi, it would be interesting to see how new 32bit register can be used in 64bit architecture which may

In BPF, an ADD instruction is defined as a 2 register instruction: 0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def _rr : ALU_RR<BPF_ALU64, Opc, (outs GPR:$dst), (ins GPR:$src2, GPR:$src), "$dst "#OpcodeStr#" $src", [(set

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > This same value for EM_BPF is being propagated to glibc, > elfutils, and binutils. great! Can you share the link to glibc and the other patches? > diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.h > index 352fd8a..fb8ff71 100644 > ---

On 03/23/2013 10:51 AM, Jiong Wang wrote: > on 2013/3/23 1:52, Chris Lattner wrote: >> On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: >> >>> Hi Chris, >>> >>> could you please comment on committing TILE-Gx backend into community? >> Hi Jiong, >> >> I don't have any special advice here. It sounds like the

on 2013/3/23 1:52, Chris Lattner wrote: > On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: > >> Hi Chris, >> >> could you please comment on committing TILE-Gx backend into community? > Hi Jiong, > > I don't have any special advice here. It sounds like the general functionality level is high enough. Taking it into mainline sounds

Hello, I have one question about the ALU scheduler. If for example I have one UNIFY volume which is using ALU scheduler with the following config: volume unify type cluster/unify option namespace afr-ns option scheduler rr option scheduler alu # use the ALU scheduler option alu.limits.min-free-disk 3% # Don't create files one a volume with less than 5% free diskspace

== Data Copying when a new brick is added. == Hi. I'm a first time glusterfs user, and I'm trying to simulate what will happen when I need to add more bricks for storage capacity. My config files are below but I'll try and explain what is going on. I have 2 machines with 2 hard drives in each. I created a replicated storage system where machine a replicates to machine b.

于 2013/3/23 23:14, Tobias Grosser 写道: > On 03/23/2013 10:51 AM, Jiong Wang wrote: >> on 2013/3/23 1:52, Chris Lattner wrote: >>> On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: >>> >>>> Hi Chris, >>>> >>>> could you please comment on committing TILE-Gx backend into community? >>> Hi Jiong,

On 03/08/2013 04:48 AM, Dmitri Gribenko wrote: > On Thu, Mar 7, 2013 at 6:33 PM, Jiong Wang <jiwang at tilera.com> wrote: >> Hi all, >> >> Updated the patches for TILE-Gx backend: >> >> 1. added initial regression tests for tilegx codegen. >> 2. added initial regression tests for MC Layer. >> 3. fixed those commenting style issues. >>

On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: > Hi Chris, > > could you please comment on committing TILE-Gx backend into community? Hi Jiong, I don't have any special advice here. It sounds like the general functionality level is high enough. Taking it into mainline sounds great, so long as it is reviewed by someone. -Chris > > >

On 03/01/2013 10:42 PM, Hal Finkel wrote: > > As some of the llvm modules are in active development, for example MC > Layer, we want to return code to community repository first, so that > it will be easy to keep pace with llvm main tree. > I think this makes sense; but my impression is that the community will want a clear idea that this will be maintained and improved for the

----- Original Message ----- > From: "Jiong Wang" <jiwang at tilera.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, cfe-dev at cs.uiuc.edu > Sent: Friday, March 1, 2013 1:34:15 AM > Subject: Re: [LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor >

Submitted to bugzilla as PR 15729 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Thursday, April 11, 2013 1:13 PM To: Weiss, Eran Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Migration from JIT to MCJIT Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

On 2015/8/12 12:57, Alexei Starovoitov wrote: > On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote: >> Think about a program like this: >> >> struct strA { int a; } >> struct strB { int b; } >> int func() { >> struct strA a; >> struct strB b; >> >> a.a = 1; >> b.b = 2; >>