similar to: [LLVMdev] LLVM as a shared library

Filip Pizlo wrote: > This is exciting! > > I would be happy to help. > > >> On Aug 5, 2014, at 12:38 PM, Chris Bieneman<beanz at apple.com> wrote: >> >> Hello LLVM community, >> >> Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of

> (7) Make the C API truly great. > > I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things: > > - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims. >

On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > >> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>> (7) Make the C API truly great. >>> >>> I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an

On Tue, Aug 5, 2014 at 2:57 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > On Aug 5, 2014, at 2:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: > > (7) Make the C API truly great.

I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. Just my 2 cents. > On Nov 6, 2014, at 2:12 PM, Chris Bieneman <beanz at apple.com> wrote: > > So, I decided to try and start small. My idea here was create a ToolsSupport library, and move one small, but important function into the new library to shake

> On Aug 18, 2014, at 4:25 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > >> On Aug 18, 2014, at 3:21 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> >>>> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> >>>> Some passes take options directly in the

On Sun, Aug 10, 2014 at 1:43 PM, Filip Pizlo <fpizlo at apple.com> wrote: > I think this ignores the real problem with the MCJIT debugging interface: it doesn't give MCJIT clients any way of directly accessing and parsing the debug metadata. > Parsing the existing debug metadata isn't necessarily a good idea anyhow. It's not a stable format and is quite large. >

On Sep 18, 2013, at 8:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: >> LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps

> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> Some passes take options directly in the constructor. For example >> >> Inliner::Inliner(char &ID, int Threshold, bool InsertLifetime) >> >> Maybe we could just say that there are two different types of options. >> The ones we want to expose to users

On Wed, Sep 18, 2013 at 9:06 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 18, 2013, at 8:58 AM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: > > LLVM's internal command line library needs to evolve. We have an immediate > need to build LLVM as a library free of static

Hi Filip Thank you for your detailed explanation, I was actually looking to implement an adaptive approach which is basically when some function executed more frequently, I was trying to drop that function and compiled and linked with new optimized function. I just did the following - whenever some function executed more times , I called-back to program, so I that I

That's a good point.  But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT").  The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip                  Addition to my previous

Hi Currently , I have doing some experimental work by using llvm, Is it possible to drop the machine code once it has been generated for particular function while program executing. For example some *void test(int)* function has been executed on native machine , I want to drop the code before I start execute some other function in my long running program. Thanks. With regards Sri.

> On Nov 6, 2014, at 3:00 PM, Reid Kleckner <rnk at google.com> wrote: > > On Thu, Nov 6, 2014 at 2:42 PM, Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: > I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. > > +1, you will need to do this if you want

I think it's great to make a policy for reporting security bugs. But first, yes, we need to be clear as to what sorts of things we consider as "security bugs", and what we do not. We need to be clear on this, both for users to know what they should depend on, and for LLVM contributors to know when they should be raising a flag, if they discover or fix something themselves. We could

Hi all, It is my understanding that now WebKit depends on the stack map functionality in production. Also, on the mailing lists we've seen lots of users using in this feature. Can we eliminate the experimental status for 3.5? Off the top of my head, the changes needed are: - A read-through of StackMaps.rst to remove any mention of it being experimental. - Removing mention of it being

Below is an outline of various usage models for MCJIT that I put together based on conversations at last month's LLVM Developer Meeting. If you're using or thinking about using MCJIT and your use case doesn't seem to fit in one of the categories below then either I didn't talk to you or I didn't understand what you're doing. In any case, I'd like to see this get

I’d like to propose moving forward with the first phase of my proposal to make the cl::opt structures owned and eliminate global option storage. I’d also like to add to it that when updating passes I will ensure that each pass that has cl::opts also has a default constructor, an overridden constructor to populate each option, and the corresponding factory methods for the C API. Does this sound

Today command line arguments in LLVM are global variables. An example argument from Scalarizer.cpp is: static cl::opt<bool> ScalarizeLoadStore ("scalarize-load-store", cl::Hidden, cl::init(false), cl::desc("Allow the scalarizer pass to scalarize loads and store")); This poses a problem for clients of LLVM that aren’t traditional compilers (i.e. WebKit, and Mesa).

On Dec 9, 2013, at 11:08 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Below is an outline of various usage models for MCJIT that I put together based on conversations at last month’s LLVM Developer Meeting. If you’re using or thinking about using MCJIT and your use case doesn’t seem to fit in one of the categories below then either I didn’t talk to you or I didn’t understand