> > The reason is that ParseIR needs to make calls to LLVM functions to create
> > the llvm::Module.
>
> I get this part, my main question is whether we can initializeLLVM in the
> Target constructor but do option resetting in enter/exit, i could miss
> something here.
I see what you mean. My
Logically, there are two kinds of operations involved:
- K0: operations that deserializes/deserializes the data structure
(llvm::Module)
- K1: operations that transforms the llvm::Module
We are certainly in agreement that all K1 should be enclosed with option
save/recovery scope. Parse/Save see
It does, yes:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L91-L99
The flags above come from the latest development branch, so in order to handle
all LLVM versions we'd need to check all of them since 4.0 (which I'm ok
doing), and we will need to keep
following up on this, I think we are in broad stroke agreement that we can
achieve our goals with blocl/fn attributes in IR as well as builtin assume. As
a result, my original blocker for the RFC has been resolved, would still be
great to work together to flesh out the details of schedule primit
cc @Hzfengsy @wrongtest-intellif it would be great if you can also take a
followup look
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/77#issuecomment-1180607081
You are receiving this because you are subscribed to this thread.
Message ID:
@tqchen i think one goal we should have with this RFC is to codify things like
> When a function does not have global_symbol attribute, it means the
> LinkageType is private
the purpose is not to codify it so that we can't change it, but just so that we
are all on the same page here. perhaps we
i've put this RFC on the meeting agenda for this week's Community Meeting
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1180909624
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks everyone for the very fruitful discussions! We indeed have a good path
forward and are aligned on the principles that for the end to end optimization
we will maintain function interface invariance and achieve graph level layout
optimization via a combination of local decisions, reconstruc
@yelite It's a great RFC，and this is what we need right now.
the requirements we need:
1) For compute fusion. With TE compute, it's easy to concate TE computes with
producer-comsuer relation to get a fused compute. for example, conv + elemwise
ops fusion. We should have similar function in TVM s
