similar to: [LLVMdev] [RFC] Developer Policy for LLVM C API

Hi Juergen, Sean, I definitely agree with needing to write down the policy and definitely any policy should include a deprecation time :) Did you want to write up something and let us poke at it? A couple of thoughts outside of a deprecation policy: a) guarantee that the api itself won't go away, but could possibly be turned into a noop? (i.e. source compatibility) b) versioning? (Should

On Fri, Jul 17, 2015 at 3:41 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Juergen, > > I've actually got another, perhaps more radical, plan. Let's just get rid > of the C API or move it to another project. This simplifies a lot of the > plans here where people have too many different ideas of how the C API > should work. > > At this point the

+1, I agree with keeping the existing C API stable, and requiring one release of deprecation with an alternative in place to remove something from it. Nobody is going to take the time to design a well-thought out C API that is powerful enough for frontend IRGen and is forward compatible with future versions of LLVM. That's an unsolved problem. We should stick with what we have. The only

On Mon, Jul 20, 2015 at 3:20 PM Jim Grosbach <grosbach at apple.com> wrote: > On Jul 20, 2015, at 2:24 PM, Jim Grosbach <grosbach at apple.com> wrote: > > > On Jul 20, 2015, at 1:45 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> Wow, this

I also misunderstood your original transition proposal in this point. I agree with Jim that we should keep the current C-API where it is and have a separate location for the bindings. I envision that we will need the current C-API and the new stable C-API to overlap for at least one release cycle to allow a smooth transition without breaking all the clients out there. Some clients only read the

On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> wrote: > I also misunderstood your original transition proposal in this point. I > agree with Jim that we should keep the current C-API where it is and have a > separate location for the bindings. I envision that we will need the > current C-API and the new stable C-API to overlap for at least one release

I think the idea of having a (hopefully not too) fluid C API that can encompass everything people want to be able to do in the language of their choice and calls into LLVM to do work sounds like a great idea. I think it would be useful to expand the number of people who are able to do research and development with LLVM without having to reinvent LLVM. That said, this is directly at odds with our

On Wed, Jul 29, 2015 at 3:28 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> I also misunderstood your original transition proposal in this point. I >> agree with Jim that we should keep the current C-API where it is and have a >> separate location for the

On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen <ak at linux.intel.com> wrote: > > Juergen Gross <jgross at suse.com> writes: > > > The long term plan has been to replace Xen PV guests by PVH. The first > > victim of that plan are now 32-bit PV guests, as those are used only > > rather seldom these days. Xen on x86 requires 64-bit support and with > > Grub2

> On Jul 20, 2015, at 1:45 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: > Wow, this went of topic very quickly ;-) > > > It did. I am sorry about that :) > > As you know I am very interested in an stable API (C and/or

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

Adding Juergen to the thread. On Fri, Mar 15, 2019, 12:20 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Ping. > > > > Would anyone be opposed to me trying to revive the in-tree Mach-O TAPI > code? > > > > Thanks, > > Shoaib > > > > *From: *Shoaib Meenai <smeenai at fb.com> > *Date: *Wednesday, March 6, 2019 at

I see. We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the

On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Chiming in with http://reviews.llvm.org/D10725 > > Being able to read and generate IR is at least some very basic thing we > can agree on is needed. Can we get some testing for it ? Personally I don't > really mind if this is going to be stable or not, but at least, having some

Sounds good. Lets get started by nailing down the C API and semantics for this first. I mirrored the C API for the LLVM context diagnostic handler and used Andy’s suggested name for the callback. The opaque handle was suggested by Duncan and can provide optional user specified information that is provided back during the callback (i.e. barrier, etc). Cheers, Juergen Core.h: typedef void

Hi all, It looks like Juergen landed the TextAPI libraries for Mach-O in https://reviews.llvm.org/D53945, and also had several follow-ups, but then it was deleted entirely by r347874. I'm not sure if the entire deletion was intentional, since the commit message only mentions reverting a certain series of patches; CC Hans. In any case, I'm wondering if there are plans to revive it, since

On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com> wrote: > I see. We still can use that shortcut to catch the simple case after type > legalization, but we could also do a more elaborate type check before type > legalization to enable it? > If you're going to write the code to check the types anyway, it's probably clearer to remove the

Wow, this went of topic very quickly ;-) As you know I am very interested in an stable API (C and/or C++) for LLVM, but maybe we should discuss this in a separate thread. Designing a good stable API from scratch will take some time and until that point I want to document our current “tribal knowledge”. I will post a patch as you suggested. —Juergen > On Jul 20, 2015, at 1:08 PM, Eric

Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug 19, 2013 at 4:17 PM, Juergen

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;