similar to: git llvm push not working?

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

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

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

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

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,

[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

On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > Hi, > > Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. > > Instructions are defined as follow in TableGen: > defm ADD64 : ALU32<"add", 1, 1, addc>; > defm ADD64C : ALU32<"addrc", 1, 2, adde>; > >

Hi, Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. Instructions are defined as follow in TableGen: defm ADD64 : ALU32<"add", 1, 1, addc>; defm ADD64C : ALU32<"addrc", 1, 2, adde>; Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to

Hi Francois, If you model the effect of your carry on the instructions, the scheduler (and the other backend passes) should ensure that nothing that affects the carry will be inserted between your two instructions (assuming they are issued with nothing affecting the carry in between in the first place). Therefore, you shouldn’t have to force them to be stuck together. If you still do, what Jakob

Hi Jakob, If glue operands are used by the scheduler to keep instructions together, why can't the register allocator also do this? Regards, Sam On 15/04/2013 23:12, Jakob Stoklund Olesen wrote: > On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > >> Hi, >> >> Let's say we have a 32-bit architecture where 64-bit additions are

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_

I really have to force them to stuck together otherwise the carry will just not work. How about wrapping the 2 instructions in a bundle? Would that be a way? http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi Francois, > > If you model the effect of your carry on the instructions, the

Using bundles here looks like a fragile way to handle that, IMHO. Really, using a pseudo instruction seems the best approach for you. For instance, you can match your add64 during isel with your pseudo instruction and expand it just before emitting the assembly file (add a pass using the hook: addPreEmitPass on your target). -Quentin On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000

Hi, I've tagged the 5.0.1-rc2 release, go ahead and start testing and report your results. -Tom

Hi, I have a case that for pointer with address space attribute, pointer arithmetic is not work. For example, -bash-4.4$ cat test.c #define __user __attribute__((address_space(1))) void __user * test(void __user *arg) { #ifdef ADD return arg + 4; #else return arg; #endif } -bash-4.4$ -bash-4.4$ clang -g -c test.c -bash-4.4$ clang -g -c -DADD test.c clang-10: ../lib/IR/Instructions.cpp:2749:

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], > >

Thanks for the detailed info! The problem was that I tried without assertions and didn't inspect the IR closely as it contained this, for now, illegal instruction: %6 = bitcast i8* %5 to i8 addrspace(1)* This is clearly a clang error. I suggest opening a bug report, or sending the reproducer to cfe-dev at llvm.lists.org so someone will take a look that has more clang experience. @Matt Do

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