similar to: 5.0.1-rc2 has been tagged

Hi, Tom, Considering the severity of this bug, I would like to go ahead to push the fix into release_50 branch. The fix has been tested in the trunk and by various people as well and I will also make sure all BPF tests passed before the push. Thanks! Yonghong On Fri, Dec 1, 2017 at 10:18 AM, Y Song <ys114321 at gmail.com> wrote: > Hi, Tom, > > I have a BPF backend bug which is

Zig tests using Debug build of 5.0.1rc2 hit this bug: https://bugs.llvm.org/show_bug.cgi?id=34452 I suppose the fix has not been backported to 5.0.1. So I created a Release build of 5.0.1rc2 and all zig tests pass, with the following patches: * Patches to LLD: commit a206ef34bbbc46017e471063a4a1832c1ddafb0a Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:11:55 2017

Thanks. That is good suggestion. I will start to work on 4.0 now. It would be good to know the 4.0.x patch release schedule and how to contribute. I found this email containing backporting timeline for 4.0.1 (already done): http://lists.llvm.org/pipermail/llvm-dev/2017-March/111530.html >From email, it is not clear to me whether we have upcoming 4.0.2 or not. Thanks! Yonghong On Fri, Jul

Hello. I've tried to add some simple arithmetic vector operations to the BPF backend available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD

Hi, I want to backport the following three patches (currently in trunk 5.0) to 3.8/3.9/4.0: https://reviews.llvm.org/rL305560 https://reviews.llvm.org/rL305608 https://reviews.llvm.org/rL306685 Some BPF users want them since their product needs to work on old linux distribution which has older versions of LLVM. Could somebody (maybe Tom Stellard or others) help clarify whether it is possible

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

Hello. I have extended the BPF back end with vector registers (inspiring from Mips MSA) - something like this: def MSA128D: RegisterClass<"Connex", [v128i16], 32, (sequence "Wh%u", 0, 31)>; I also added vector store and load instructions in the style of Mips MSA - see

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

Hi, I have two BPF related patches, clang: https://reviews.llvm.org/D65615 llvm: https://reviews.llvm.org/D65617 The llvm patch changes one IR Builder function signature: from: Value *CreatePreserveArrayAccessIndex(Value *Base, unsigned Dimension, unsigned LastIndex) to Value *CreatePreserveArrayAccessIndex(Value *Base, unsigned Dimension,

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,

Hi all, I am trying to insert instructions into the bpf using the bpf syscall, the instructions were generated using the following command line: clang -I ~/Builds/bpf_rss/iproute2/include -Wall -target bpf -O2 -emit-llvm -c upstream/qemu/hw/net/rss_tap_bpf_program.c -o - | llc -march=bpf -filetype=obj -o tap_bpf_program.o and then were translated to bpf instructions using the BPFCparser tool

Hello. I am writing a back end in which I combined the existing BPF LLVM back end with the Mips MSA vector extensions (from the Mips back end) I have encountered an error when compiling with llc: the instruction selector uses a vector register instead of a scalar register with type i64 . I have the following part of LLVM IR program: vector.body.preheader:

Spills created at the end of the block (I assume you mean what fast regalloc does at -O0) are created long after instruction selection. In that case it sounds like your implementation of storeRegToStackSlot/loadRegFromStackSlot is broken -Matt On Tue, Oct 25, 2016 at 7:30 AM +0800, "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>

On Fri, Oct 25, 2019 at 2:10 PM Tim Northover <t.p.northover at gmail.com> wrote: > > Hi Yonghong, > > On Fri, 25 Oct 2019 at 13:40, Y Song via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The `git llvm push` used to work for me. Not it stopped working. > > > > Does anybody know what have changed recently? > > We recently switched to git and

On Mon, Sep 24, 2018 at 3:53 PM Tim Northover <t.p.northover at gmail.com> wrote: > > On Thu, 13 Sep 2018 at 10:58, Sameeh Jubran via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I am not sure how to debug this error since the instructions are in > > binary and the precompiled source code doesn't seem to contain any > > weird loops or goto

Hi, I tried to push the diff https://reviews.llvm.org/D69438 to trunk following instructions at https://llvm.org/docs/GettingStarted.html#commit-from-git Specially, I have done the following setup: $ export PATH=$PATH:$TOP_LEVEL_DIR/llvm-project/llvm/utils/git-svn/ But my `git llvm push` did not really do the push as shown below: -bash-4.4$ git llvm push `git fetch

I forgot the -DADD flag earlier but the result did not change: https://godbolt.org/z/NPcn22 ________________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Doerfert, Johannes via llvm-dev <llvm-dev at lists.llvm.org> Sent: Wednesday, October 30, 2019 20:18 To: LLVM Developers Mailing List; Y Song Cc: Alexei Starovoitov Subject: Re: [llvm-dev]

On 01/11, Daniel Berlin via llvm-dev wrote: > > > > def int_experimental_directive : Intrinsic<[], [llvm_metadata_ty], > > [IntrArgMemOnly], > > "llvm.experimental.directive">; > > > > def int_experimental_dir_qual : Intrinsic<[], [llvm_metadata_ty], > > [IntrArgMemOnly], > >

Hi, I'm going to club together some responses. I agree that outlining function sub-bodies and passing in the function pointers to said outlined bodies to OpenMP helpers lets us correctly implement the semantics we need. However, unless I severely misunderstood the thread, I thought the key idea was to move *away* from that representation and towards a representation that _allows_

[XT] Back from Biz trips, trying to catch up with the discussion. >>>>I agree that outlining function sub-bodies and passing in the function pointers to said outlined bodies to OpenMP helpers lets us correctly implement the semantics we need. However, unless I severely misunderstood the thread, I thought the key idea was to move *away* from that representation and towards a