[TVM Discuss] [Development] Google lasted work: MLIR Primer

It’s true. Handcrafting doesn’t scale when # of ASICs increases. --- [Visit Topic](https://discuss.tvm.ai/t/google-lasted-work-mlir-primer/1721/23) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm

Re: [dmlc/tvm] [VOTE] Apache Transition Plan (#2973)

+1 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2973#issuecomment-481145860

Re: [dmlc/tvm] [RFC][AUTOTVM] Auto-Schedule from Compute Declaration (#2954)

@eqy "injective" is considered "direct compute". Typically they will be inlined. Serializable Template + Serializable Config seems to be a good direction to go. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.

[TVM Discuss] [Development] Google lasted work: MLIR Primer

[quote="junrushao1994, post:23, topic:1721, full:true"] It’s true. Handcrafting doesn’t scale when # of ASICs increases. [/quote] Hmm I dont think TVM really has a bigger problem of hand-crafting (read my comment to the next quote), also I think every ASIC developer would have to commit to "at

[TVM Discuss] [Development] Google lasted work: MLIR Primer

Good tensorizor is an open problem that we all need to solve. Poly do not have advantage or disadvantage in this problem. This is a technical direction we should push to solve in TVM. The common part between Poly and TVM is the usage of integer and integer set analysis. On that end, TVM and H

[dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

As we discussed in https://github.com/dmlc/tvm/issues/2715, most of us agree with switch to Python3 starts with 0.6 release. I want to start a vote to deprecate Python2 support & test in dev branch now, so in starts from 0.6 release, only Python3 is supported. -- You are receiving this becaus

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

Ah finally! So much +1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481341057

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 > On Apr 9, 2019, at 10:14 AM, Nick Hynes wrote: > > Ah finally! So much +1 > > — > You are receiving this because you are on a team that was mentioned. > Reply to this email directly, view it on GitHub > , or mute the > threa

[TVM Discuss] [Development] [DISCUSS] Contributing new docs for InferBound

Hi all. There's been lots of discussion about improving TVM documentation. I noticed that there isn't much documentation for the InferBound pass, but I think it's an interesting part of the code, that's fundamental to understanding how lowering works in TVM. After all, InferBound is essential

[TVM Discuss] [Development] Disable assert in runtime

Hi there, In current tvm, src/codegen/llvm/codegen_cpu.cc, it generate assert stmt. It would be nice to have a build config option to disable these runtime TVM asserts. Below is just a example of disable it with environment variable. It will be better to use build config to control it. Plea

[TVM Discuss] [Development] Export LookupLLVMIntrinsic for C++ users

Since tvm depends on llvm, perhaps one way to do so is to directly use the related function in LLVM. Alternatively, you can get the feature by getting the corresponding PackedFunc from the global registry and call from there --- [Visit Topic](https://discuss.tvm.ai/t/export-lookupllvmintr

[TVM Discuss] [Development] Disable assert in runtime

This is a reasonable feature that I agree we could put into build config option. Contributions are welcomed! --- [Visit Topic](https://discuss.tvm.ai/t/disable-assert-in-runtime/2152/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these em

[TVM Discuss] [Development] Export LookupLLVMIntrinsic for C++ users

Thanks for the reply. Totally understand your point. But I believe there is a point to export LookupLLVMIntrinsic in C++, which could open the portal for fine grain control for users to directly call the llvm intrin they want, e.g. like avx2 related instructions. User could have more flexibil

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481411885

[TVM Discuss] [Development] Google lasted work: MLIR Primer

Good discussions here, the design principle of TVM stack is to "be intelligent and pragmatic". This means we want as much automation as possible, but also provide ways to make use of human domain information like schedule template, tensorized micro-kernels when necessary. We will likely contin

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1, I think we agreed on python3.5 support to be safe because many users' system still only have 3.5 installed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481419067

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1. We (The relay crew) often find not having py3 features(fstring, keword only argument, type annotation, nonlocal) inconvenient. Can we get it to 3.6? fstring(3.6 feature) is used heavily in the relay ahead of time compiler that will be opensourced soon. -- You are receiving this because you

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481432475

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481453561

Re: [dmlc/tvm] [RFC][Graph Tuner] Graph level auto-tuning (#1585)

@FrozenGene Data of "apply_history_best" updated. @yzhliu Updated some implementation details. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/1585#issuecomment-481464375

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481469077

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481480998

Re: [dmlc/tvm] [Vote] Deprecate Python2 Support (#2994)

👍 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2994#issuecomment-481482279

Re: [dmlc/tvm] [VOTE] Apache Transition Plan (#2973)

+1 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2973#issuecomment-481488643

[TVM Discuss] [Development] Google lasted work: MLIR Primer

Actually the current MLIR document says that polyhedral IR is an experimental dialect of MLIR. I find that a bit odd that they would call it "experimental". BTW I presented polyhedral compilation of ML graphs at C4ML ... and I think that polyhedral and functional approaches like Relay IR are w

[TVM Discuss] [Development] [DISCUSS] Contributing new docs for InferBound

Haven't had the chance to read the full post yet, but wanted to just say this looks great, and the kind of things we need more of! We've been chatting about outlining a new structure for the docs and I think this kind of technical documentation would be good to put into a dev's guide to workin

[TVM Discuss] [Development] [DISCUSS] Contributing new docs for InferBound

Looks good. We can also highlights the design consideration besides the current restrictiions. For example, the usage of IntSet as abstraction is an important design choice. While the current realization mainly depends on intervals, we can certainly improve the integer set representation wit