It's not in my backlog for this quarter, but it's something we could look in to.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tvm-documentation-refactor/7456/8)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
h
HI @tqchen ,
I will try to sporadically comment, since this is a project I prototyped (and
enjoyed :) ) when I was in Arm.
If I understand your comment correctly, what @MeeraN7 is doing is closer to
what you are proposing. Instead of transforming a loop into a Ramp, and passing
the ramp "as i
I recently encountered similar issues. We can extent legalization/lowering to
match this pattern `Evaluate(call_intrin))` and lower them to `Stmt`
---
[Visit
Topic](https://discuss.tvm.apache.org/t/handling-of-prefetch-legalization-lowering/10718/2)
to respond.
You are receiving this bec
Currently a `PrefetchNode` is replaced with a loop nest doing single cache line
prefetches, and that's done in the storage flattener. This is bad for Hexagon,
because Hexagon has a prefetch engine which can prefetch a 2D buffer in the
background, but it requires a different setup. Once the l
Follow up issues that should be fixed:
- The latest fix on this PR breaks on NRF board which seems to be because of
`prj.conf` misconfiguration.
- stm32l4r5zi_nucleo is removed from the hardware target list.
- It also fails on disco board with similar error to NRF:
```
may be incomplete.
make[2]:
I do not disagree, that is why I think the argument can go both ways. One pt
here though is that legalization means we need to recursively call the lowering
strategy on the return expr of the legalized code, while in the case of
lowering we do not need to do so.
We could certainly name all t
The goal is to rewrite the TIR into a way that the target's codegen can handle.
Rewriting `exp` into `llvm.exp` can be seen as legalization too. There can be
targets that can generate code directly for `exp`. In fact, the translation
from `exp` to `llvm.exp` is only there for convenience (au
Most op likely will have a generic legalization strategy(in case target
lowering strategy does not exist), and specific lowering strategy per target
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/11)
to respond.
You are re
Sorry I was posting on a wrong thread
@kparzysz Thanks for asking! For example, there might be some rare TVM
intrinsics like `tir.erf` that may be lowered to some cuda intrinsic (using
`Lowering`), but those intrinsics aren't guaranteed to exist on other hardware
platforms, and in this case,
@kparzysz Thanks for asking! For example, there might be some rare TVM
intrinsics like `tir.erf` that may be lowered to some cuda intrinsic (using
`Lowering`), but those intrinsics aren't guaranteed to exist on other hardware
platforms, and in this case, we substitute the intrinsic with more c
Thanks @kparzysz . I believe the argument can go both ways in here. If we view
the overall IR as "staged", lowering means we have a strategy to map them to
the corresponding low level intrinsics.
While legalization means we remap the op by composing using other expressions,
which still need
Why would an op have both? This is still the question that hasn't been
answered. What was the intent behind having "lowering" and "legalization" as
different things?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/8)
to r
I do agree that we don’t want abstractions that are not useful.
Just to explain a bit more: any op could have both legalization and intrinsic
lowering function. Type-wise, yes they are all TIR expressions and technically
there’s no difference. Concept-wise, since any op can have both implement
We should have a way of legalizing builtins/intrinsics that can involve
creating new statements. Not every builtin may be replaceable with an
expression. Has anybody thought about doing that?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/new-target-intrinsic-lowering-and-legalizati
>From what I've seen so far there is no difference at all, conceptual or not.
>We should stick to one and get rid of the other. Both operate on the same TIR
>representation. In one case the TIR expression is replaced by another
>function call, in the other the resulting expression is more c
So technically I don’t think they are very different in behavior, i.e., the
type of functions are the same in TIR. It’s more of a conceptual difference for
now.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/5)
to respond.
Legalization is when there is no available op intrinsic lowering function
available, we might use other op to combine and implement some op. For example,
[here](https://github.com/apache/tvm/blob/3d380fc5817ce335ea823ce7e6b7e35717e579cd/src/target/llvm/intrin_rule_llvm.cc#L106)
the exp10 op on
Intrinsics and ops are represented in the same way in TIR though. What is the
intended behavior of "legalization" that is different from "lowering"?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/3)
to respond.
You are re
Hi, good catch! They are designed to deal with op intrinsic lowering and op
legalization respectively in the lowering pass. Ideally, we always want to use
intrinsic lowering before legalization if available. I don't think we are going
to phase out any of them for now because there could be div
Just found this thread. [What's the intended difference between lowering and
legalization?](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/2)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/new-target-intrinsic-lowering-and-legalization-m
Both, `FLowerIntrinsic` and `FLegalize` are the same type, and they are handled
in a pretty much the same way. Is one of them being phased out?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/1)
to respond.
You are receivi
let us wait for another two days and if there is no objection, we can merge it
in
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/17#issuecomment-893562583
cc @junrushao1994 @vinx13 as it can be related to the future tensorization
optimizations
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-893552428
Thanks @MeeraN7 for the RFC. SVE is certainly an interesting topic that can be
covered in different ways.
It would be very helpful to also show examples of the code along the
transformations, so we can have a better understanding the possible design
tradeoffs.
Specifically:
- The TIR before
@sjoerdmeijer @giuseros
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-893458074
Add a PaddlePaddle frontend for TVM, also I have created [a RFC topic in
forum](https://discuss.tvm.apache.org/t/rfc-add-a-paddlepaddle-frontend/10692)
where we can discuss at same time.
The related pull request is https://github.com/apache/tvm/pull/8645, still lack
of UT, which will be finished
26 matches
Mail list logo
