similar to: [ORC] [mlir] Dump assembly from OrcJit

I can use llc to compile my IR module to amdgcn with some non-zero output. However, if try to write the output (assembly or object) to a string (via buffer_ostream) the resulting string has always zero length. Here the code changes I do: Original llc:       if (Target->addPassesToEmitFile(PM, *OS,                                       DwoOut ? &DwoOut->os() : nullptr,

On Tue, Sep 10, 2019 at 1:40 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > But perhaps more importantly, as Hal states clearly, is the need for > > an official specification, similar to the one for LLVM IR, as well as > > a formal document with the expected semantics into

Hi all, The TensorFlow team at Google has been leading the charge to build a new set of compiler infrastructure, known as the MLIR project <https://github.com/tensorflow/mlir>. The initial focus has been on machine learning infrastructure, high performance accelerators, heterogeneous compute, and HPC-style computations. That said, the implementation and design of this infrastructure is

Overall, I think it will be a good move. Maintenance wise, I'm expecting the existing community to move into LLVM (if not all in already), so I don't foresee any additional costs. Though, Hal's points are spot on... On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 3. As a specific example of the above, the current development

On Wed, Sep 11, 2019 at 1:54 PM David Greene <greened at obbligato.org> wrote: > Mehdi AMINI <joker.eph at gmail.com> writes: > > > Of course by its nature, MLIR doesn't lend itself to concrete semantic > >> descriptions, though I would expect the affine dialect (and others) to > >> have documentation on par with the LLVM IR. > > > > >

On Mon, 9 Sep 2019 at 22:22, Chris Lattner <clattner at google.com> wrote: > Including a bunch of content, eg a full langref doc: > https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md Thanks Chris, that looks awesome! This one could perhaps be improved with time: https://github.com/tensorflow/mlir/blob/master/g3doc/ConversionToLLVMDialect.md Which I think was Hal's

I looked around for the status of OrcJIT FFI support. The last e-mail thread I could find was this one: Link <http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html> Raw: http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html Is OrcJIT now considered stable enough that there can be "official" exposed C APIs? If not, what's the standard approach if I

Hi, (bcc: mlir at tensorflow.org FYI) I am following-up on the integration of MLIR in LLVM as a subproject (Re: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135687.html ). We're aiming to integrate into the monorepo next month. Right now our intent is for MLIR to live in a top-level directory in parallel to clang, lldb, lld, etc. Our top option for the integration is to perform a

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Nov 15, 2019 at 8:54 AM James Y Knight <jyknight at google.com> wrote: > > > On Fri, Nov 15, 2019 at 5:03 AM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> (bcc: mlir at tensorflow.org FYI) >> >> I am following-up on the integration of MLIR in LLVM as a subproject (Re: >>

Hello, I was wondering if there is someone already working on putting the new OrcJIT APIs in the LLVM-C bindings? Also, is there a general consensus to also add C bindings when new major features are added? Hayden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/061f5949/attachment.html>

Hi folks, Git is on its way to learning how to ignore commits, allowing us to do variable renaming and other small refactorings without breaking git blame. It's like git-hyper-blame [1] but significantly more powerful as it uses fuzzy matching to match lines, including lines that may have been split or joined. A preview release of Git with this new feature is at:

I've been playing with OrcJIT a bit, and from the looks of it I can (like in the previous JIT I suppose?) ask for a function to be re generated. If I've given the address of the function that LLVM gave me to an external party, do "I" need to ensure thread-safety? Or is it safe to ask OrcJIT to re generate code at that address and everything will work magically? I'm

This thread is not active for a while, but I'm still interested in seeing a change. Reading through this thread, looks like we can agree that we want to change the local variable naming scheme so that they start with a lowercase letter. Besides that, there were discussions about lower_case, camelCase, m_ prefix, and each argument seems as convincing as others. I'm not sure what is the

Thanks, David. I'd be happy to add the bindings .. is there a general way we add them? Or do you just scrub the API and make sensible judgements to the API? On Sun, Feb 1, 2015 at 1:55 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sun, Feb 1, 2015 at 10:58 AM, Hayden Livingston <halivingston at gmail.com > > wrote: > >> Hello, >> >> I

Hello everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them,

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

On Mon, Jun 10, 2019 at 6:27 PM Michael Platings <Michael.Platings at arm.com> wrote: > Hi Rui, > > > > As per the provisional plan [1] we’re still at step 1: improving git > blame. The status of this is that there are some fairly mature patches in > the Git project’s queue [2], and I’m hopeful that it will be accepted in > something close to its current form. >

This looks really great to me Rui, and I’m also pleased to see the positive comments on the review thread. Thank you for driving this forward! -Chris > On Jul 4, 2019, at 9:50 PM, Rui Ueyama <ruiu at google.com> wrote: > > Hi all, > > I wrote a tool <https://reviews.llvm.org/D64123> to batch-rename variable names so that they are in camelCase, and I applied the

Hi Rui, Is your tool in a good state to be run on people's downstream repositories? It would be nice to be able to update variable names there too at the same time. James On Tue, 9 Jul 2019 at 08:24, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks, Chris. > > Looks like everybody is at least mildly comfortable with my variable name > renaming change,