MLIR sub-dialects

[Sana Damani]

Is it considered good practice to create sub-dialects that inherit from a common dialect? For instance, the XLA compiler today supports GPU/CPU/TPU paths, each of which have different target-specific optimizations such as fusion. Will the MLIR compiler have a global XLA dialect and 3 XLA sub-dialects, one for each target architecture? Or should MLIR dialects be target-independent until code generation at which point the LLVM back-end handles target specific optimizations?

[Tatiana Shpeisman]

You can create both target-dependent and target-independent dialects. We currently do not have a concept of dialect inheritance.

We have XLA dialect in MLIR. It has not yet been release in the open source but will be soon. The XLA dialect models HLO, so it is target independent. 

On Mon, Jun 10, 2019 at 10:23 AM Sana Damani <sana....@intel.com> wrote:

Is it considered good practice to create sub-dialects that inherit from a common dialect? For instance, the XLA compiler today supports GPU/CPU/TPU paths, each of which have different target-specific optimizations such as fusion. Will the MLIR compiler have a global XLA dialect and 3 XLA sub-dialects, one for each target architecture? Or should MLIR dialects be target-independent until code generation at which point the LLVM back-end handles target specific optimizations?

--
You received this message because you are subscribed to the Google Groups "MLIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/d914ad67-1f07-4615-b427-d2b96b11b2a2%40tensorflow.org.

[Sana Damani]

Thank you for your response Tatiana.

Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).

I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

Sana

On Monday, June 10, 2019 at 10:29:01 AM UTC-7, Tatiana Shpeisman wrote:

You can create both target-dependent and target-independent dialects. We currently do not have a concept of dialect inheritance.

We have XLA dialect in MLIR. It has not yet been release in the open source but will be soon. The XLA dialect models HLO, so it is target independent. 

On Mon, Jun 10, 2019 at 10:23 AM Sana Damani <sana....@intel.com> wrote:

Is it considered good practice to create sub-dialects that inherit from a common dialect? For instance, the XLA compiler today supports GPU/CPU/TPU paths, each of which have different target-specific optimizations such as fusion. Will the MLIR compiler have a global XLA dialect and 3 XLA sub-dialects, one for each target architecture? Or should MLIR dialects be target-independent until code generation at which point the LLVM back-end handles target specific optimizations?

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

[Mehdi AMINI]

On Mon, Jun 10, 2019 at 10:50 AM Sana Damani <sana....@intel.com> wrote:

Thank you for your response Tatiana.

Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).

It isn't clear to me that you need "inheritance", my view today is that you can already extend a dialect by adding new operations in a new dialect.

A dialect defines a set of types and operations to operate on these types: you cannot easily extend the set of types because the operations in this dialect have their own definitions with respect to the types and the set of transformations on this dialect likely make assumptions on the set of types these operations can take. On the other hand, you can always provide new operations that reuse these types in your own dialect, and having a function having a mix of operations from both dialects.

 

I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

I think XLA HLO would be a single dialect, but transformations/optimizations and lowering can be specific to a target, does it fit your mental model?

-- 

Mehdi

 

On Monday, June 10, 2019 at 10:29:01 AM UTC-7, Tatiana Shpeisman wrote:

You can create both target-dependent and target-independent dialects. We currently do not have a concept of dialect inheritance.

We have XLA dialect in MLIR. It has not yet been release in the open source but will be soon. The XLA dialect models HLO, so it is target independent. 

On Mon, Jun 10, 2019 at 10:23 AM Sana Damani <sana....@intel.com> wrote:

Is it considered good practice to create sub-dialects that inherit from a common dialect? For instance, the XLA compiler today supports GPU/CPU/TPU paths, each of which have different target-specific optimizations such as fusion. Will the MLIR compiler have a global XLA dialect and 3 XLA sub-dialects, one for each target architecture? Or should MLIR dialects be target-independent until code generation at which point the LLVM back-end handles target specific optimizations?

--
You received this message because you are subscribed to the Google Groups "MLIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/d914ad67-1f07-4615-b427-d2b96b11b2a2%40tensorflow.org.

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/f73a5809-57ac-4dd4-8c0a-ca8c6bb7e1e0%40tensorflow.org.

[Chris Lattner]

> On Jun 10, 2019, at 10:50 AM, Sana Damani <sana....@intel.com> wrote:
>
> Thank you for your response Tatiana.
>
> Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).
>
> I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

Right, XLA is a lot of different things depending on what part you’re referring to. Tatiana is mentioning that there can be a single dialect corresponding to the “HLOBuilder” abstraction, which is more or less target independent (though some targets only support some features).

Within this space there are a lot of open questions: several new HLOs have been added recently specifically because of targets that have optimized high level kernels (e.g. triangular decomposition on GPUs). While this is pragmatic given where we are now, in my view, this direction is eroding the original value of HLO, since it is no longer a simple set of orthogonal primitives that everything is built upon. I’m much farther away from it, but my understanding is that ONNX is also heading down a similar slippery slope.


XLA internally has other abstractions though: it has late HLO (this is a term I made up, I’m not sure the official term for this) which introduces a buffer abstractions. XLA-GPU as an IR of sorts built out of its thunks. Each of these can be modeled as MLIR dialects, and each is in various stages of discussion and evaluation by various teams.

-Chris

[Jacques Pienaar]

On Tue, Jun 11, 2019 at 7:40 AM 'Chris Lattner' via MLIR <ml...@tensorflow.org> wrote:

> On Jun 10, 2019, at 10:50 AM, Sana Damani <sana....@intel.com> wrote:
>
> Thank you for your response Tatiana.
>
> Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).

I'm curious about the use case of inheritance along with multiple dialects. One of the strengths of MLIR is that you can have multiple dialects in the same function. o if you had say an op X that is available on all CPUs and op Y that is only available in certain, then you don't need to have the dialect containing Y inherit from the one containing X. Instead you can have a function with both X and Y (even though they are in different dialects) and that function is only valid for platforms supporting Y. E.g., you would have introduced Y in the process of targeting that specific platform.

The target is very important as you and Chris mention as a lot of optimizations require knowing the target to determine which optimizations to do etc. Which is another interesting discussion point :)

-- Jacques

 

>
> I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

Right, XLA is a lot of different things depending on what part you’re referring to.  Tatiana is mentioning that there can be a single dialect corresponding to the “HLOBuilder” abstraction, which is more or less target independent (though some targets only support some features).

Within this space there are a lot of open questions: several new HLOs have been added recently specifically because of targets that have optimized high level kernels (e.g. triangular decomposition on GPUs).  While this is pragmatic given where we are now, in my view, this direction is eroding the original value of HLO, since it is no longer a simple set of orthogonal primitives that everything is built upon.  I’m much farther away from it, but my understanding is that ONNX is also heading down a similar slippery slope.


XLA internally has other abstractions though: it has late HLO (this is a term I made up, I’m not sure the official term for this) which introduces a buffer abstractions.  XLA-GPU as an IR of sorts built out of its thunks.  Each of these can be modeled as MLIR dialects, and each is in various stages of discussion and evaluation by various teams.

-Chris

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/07BD97F7-ACD7-440B-8610-377CC8ECD611%40google.com.

[Alex Zinenko]

We already the NVVM dialect (https://github.com/tensorflow/mlir/blob/master/include/mlir/LLVMIR/NVVMOps.td) that extends the LLVM dialect in the way Mehdi described above: it reuses the types of the "parent" dialect and introduces new operations.  And it is target-specific in a sense that it should only be used when targeting an Nvidia GPU.  My understanding is the conversions/passes are in charge of picking the dialects they produce, and it may be useful for those to have a sort of target description.  Many transformations themselves seem target-independent to me (fusion, tiling), it's the _choice_ of which transformation to apply that is target-specific.

There is another case where operation "inheritance" pops in: when multiple operations have some common property and we may want to introduce an common abstraction for them.  For example, std.addi, std.addf, std.subi, std.subf are all conceptually "arithmetic operations" and std.addi, std.addf are "addition operations".  There may be use cases where you would want to operate on any arithmetic operation, or any addition.  The same may be interesting for some HLOs.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAM4W%2BYeGtZFuEsMvS5_MXoks%3D2AEuMUohonTCs8AXTGZ2VXKog%40mail.gmail.com.

--

-- Alex

[Sana Damani]

if you had say an op X that is available on all CPUs and op Y that is only available in certain, then you don't need to have the dialect containing Y inherit from the one containing X. Instead you can have a function with both X and Y

Hi Jacques,

You make a very interesting point. So it looks like if you want a dialect D1 with operation X and another dialect D2 with operations X and Y, you can:

(a) create a new dialect D2 with both X and Y

(b) create a new dialect D2 with only Y

(c) inherit sub-dialect D2 from D1

(d) extend dialect D1 to include Y

Option (a) would be bad practice IMO because of code duplication.

Option (b) is the mixed dialect function you described. I think that a potential issue with this would be the inability to perform analyses and transforms that operate on both X and Y (if for example you want to fuse X and Y).

Option (c) solves both problems by preventing code duplication and allowing X and Y to be part of the same dialect D2, thereby making optimizations possible.

Option (d) is what Mehdi proposed and this also solves both problems but would require additional checks to determine if a certain back-end supports operation Y. However, if you require the same operation Y in separate dialects such that the operation is defined differently either based on types supported or optimizations, inheriting multiple child classes D2 and D3 from a common base class D1 may still be useful.

Sana

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

[Mehdi AMINI]

On Tue, Jun 11, 2019 at 8:26 AM Sana Damani <sana....@intel.com> wrote:

if you had say an op X that is available on all CPUs and op Y that is only available in certain, then you don't need to have the dialect containing Y inherit from the one containing X. Instead you can have a function with both X and Y

Hi Jacques,

You make a very interesting point. So it looks like if you want a dialect D1 with operation X and another dialect D2 with operations X and Y, you can:

(a) create a new dialect D2 with both X and Y

(b) create a new dialect D2 with only Y

(c) inherit sub-dialect D2 from D1

(d) extend dialect D1 to include Y

Option (a) would be bad practice IMO because of code duplication.

Option (b) is the mixed dialect function you described. I think that a potential issue with this would be the inability to perform analyses and transforms that operate on both X and Y (if for example you want to fuse X and Y).

Why would an optimization aware of Y be limited?

Option (c) solves both problems by preventing code duplication and allowing X and Y to be part of the same dialect D2, thereby making optimizations possible.

I don’t understand what is fundamentally different with b, I am still not sure what you mean by inherit?

Option (d) is what Mehdi proposed and this also solves both problems but would require additional checks to determine if a certain back-end supports operation Y. However, if you require the same operation Y in separate dialects such that the operation is defined differently either based on types supported or optimizations, inheriting multiple child classes D2 and D3 from a common base class D1 may still be useful.

I was actually proposing b :)

— 

Mehdi

Sana

On Monday, June 10, 2019 at 11:24:26 PM UTC-7, Jacques Pienaar wrote:

On Tue, Jun 11, 2019 at 7:40 AM 'Chris Lattner' via MLIR <ml...@tensorflow.org> wrote:

> On Jun 10, 2019, at 10:50 AM, Sana Damani <sana....@intel.com> wrote:
>
> Thank you for your response Tatiana.
>
> Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).

I'm curious about the use case of inheritance along with multiple dialects. One of the strengths of MLIR is that you can have multiple dialects in the same function. o if you had say an op X that is available on all CPUs and op Y that is only available in certain, then you don't need to have the dialect containing Y inherit from the one containing X. Instead you can have a function with both X and Y (even though they are in different dialects) and that function is only valid for platforms supporting Y. E.g., you would have introduced Y in the process of targeting that specific platform.

The target is very important as you and Chris mention as a lot of optimizations require knowing the target to determine which optimizations to do etc. Which is another interesting discussion point :)

-- Jacques

 

>
> I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

Right, XLA is a lot of different things depending on what part you’re referring to.  Tatiana is mentioning that there can be a single dialect corresponding to the “HLOBuilder” abstraction, which is more or less target independent (though some targets only support some features).

Within this space there are a lot of open questions: several new HLOs have been added recently specifically because of targets that have optimized high level kernels (e.g. triangular decomposition on GPUs).  While this is pragmatic given where we are now, in my view, this direction is eroding the original value of HLO, since it is no longer a simple set of orthogonal primitives that everything is built upon.  I’m much farther away from it, but my understanding is that ONNX is also heading down a similar slippery slope.


XLA internally has other abstractions though: it has late HLO (this is a term I made up, I’m not sure the official term for this) which introduces a buffer abstractions.  XLA-GPU as an IR of sorts built out of its thunks.  Each of these can be modeled as MLIR dialects, and each is in various stages of discussion and evaluation by various teams.

-Chris


--
You received this message because you are subscribed to the Google Groups "MLIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/07BD97F7-ACD7-440B-8610-377CC8ECD611%40google.com.

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/62cf0f83-6fc4-4243-b04c-09bc915ba392%40tensorflow.org.

[Sana Damani]

Hi Alex,

Thank you for pointing out the NVVM dialect. How would you say this is conceptually different from inheritance?

For example, std.addi, std.addf, std.subi, std.subf are all conceptually "arithmetic operations" and std.addi, std.addf are "addition operations".  There may be use cases where you would want to operate on any arithmetic operation, or any addition.

Yes, good point. I assume we would be using "attributes" on these common operations to distinguish between std.addi and std.addf while still allowing optimizations to read them both as "addition operations".

Many transformations themselves seem target-independent to me (fusion, tiling), it's the _choice_ of which transformation to apply that is target-specific.

That makes sense. It is the optimization profitability that changes, as well as perhaps the operations/types supported. We may want target-specific pass managers as well as a machine description like you described, instead of making the dialects themselves target-specific.

Sana

On Tuesday, June 11, 2019 at 1:51:25 AM UTC-7, Alex Zinenko wrote:

We already the NVVM dialect (https://github.com/tensorflow/mlir/blob/master/include/mlir/LLVMIR/NVVMOps.td) that extends the LLVM dialect in the way Mehdi described above: it reuses the types of the "parent" dialect and introduces new operations.  And it is target-specific in a sense that it should only be used when targeting an Nvidia GPU.  My understanding is the conversions/passes are in charge of picking the dialects they produce, and it may be useful for those to have a sort of target description.  Many transformations themselves seem target-independent to me (fusion, tiling), it's the _choice_ of which transformation to apply that is target-specific.

There is another case where operation "inheritance" pops in: when multiple operations have some common property and we may want to introduce an common abstraction for them.  For example, std.addi, std.addf, std.subi, std.subf are all conceptually "arithmetic operations" and std.addi, std.addf are "addition operations".  There may be use cases where you would want to operate on any arithmetic operation, or any addition.  The same may be interesting for some HLOs.

On Tue, Jun 11, 2019 at 8:24 AM 'Jacques Pienaar' via MLIR <ml...@tensorflow.org> wrote:

On Tue, Jun 11, 2019 at 7:40 AM 'Chris Lattner' via MLIR <ml...@tensorflow.org> wrote:

> On Jun 10, 2019, at 10:50 AM, Sana Damani <sana....@intel.com> wrote:
>
> Thank you for your response Tatiana.
>
> Are there plans to add support for dialect inheritance in the future? This may be useful when adding support for data-types (e.g. int8) and operations that are available only on certain architectures, and for optimizations that are implemented differently for each architecture (e.g. profit of fusion may vary between CPU vs GPU).

I'm curious about the use case of inheritance along with multiple dialects. One of the strengths of MLIR is that you can have multiple dialects in the same function. o if you had say an op X that is available on all CPUs and op Y that is only available in certain, then you don't need to have the dialect containing Y inherit from the one containing X. Instead you can have a function with both X and Y (even though they are in different dialects) and that function is only valid for platforms supporting Y. E.g., you would have introduced Y in the process of targeting that specific platform.

The target is very important as you and Chris mention as a lot of optimizations require knowing the target to determine which optimizations to do etc. Which is another interesting discussion point :)

-- Jacques

 

>
> I do not think XLA is entirely target independent. Today XLA has files under tensorflow/compiler/xla/service/cpu and tensorflow/compiler/xla/service/gpu which implement optimizations and code generation (e.g. cuDNN for GPU) based on the architecture.

Right, XLA is a lot of different things depending on what part you’re referring to.  Tatiana is mentioning that there can be a single dialect corresponding to the “HLOBuilder” abstraction, which is more or less target independent (though some targets only support some features).

Within this space there are a lot of open questions: several new HLOs have been added recently specifically because of targets that have optimized high level kernels (e.g. triangular decomposition on GPUs).  While this is pragmatic given where we are now, in my view, this direction is eroding the original value of HLO, since it is no longer a simple set of orthogonal primitives that everything is built upon.  I’m much farther away from it, but my understanding is that ONNX is also heading down a similar slippery slope.


XLA internally has other abstractions though: it has late HLO (this is a term I made up, I’m not sure the official term for this) which introduces a buffer abstractions.  XLA-GPU as an IR of sorts built out of its thunks.  Each of these can be modeled as MLIR dialects, and each is in various stages of discussion and evaluation by various teams.

-Chris


--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/07BD97F7-ACD7-440B-8610-377CC8ECD611%40google.com.

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAM4W%2BYeGtZFuEsMvS5_MXoks%3D2AEuMUohonTCs8AXTGZ2VXKog%40mail.gmail.com.

--

-- Alex

[Sana Damani]

Hi Mehdi,

My bad, I seem to have misunderstood your proposal.

The difference that I see between (b) and (c) would be that with inheritance, the new dialect D2 has its own variant of both X and Y operations and can analyze both, whereas with (b) there are two independent dialects, each one with a view of only one of the operations (either X or Y).

I was under the impression that an optimization could only operate on ops from a single dialect and not on ops from multiple dialects. But perhaps my assumption is incorrect?

Sana

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/62cf0f83-6fc4-4243-b04c-09bc915ba392%40tensorflow.org.

[Mehdi AMINI]

On Tue, Jun 11, 2019 at 8:44 AM Sana Damani <sana....@intel.com> wrote:

Hi Mehdi,

My bad, I seem to have misunderstood your proposal.

The difference that I see between (b) and (c) would be that with inheritance, the new dialect D2 has its own variant of both X and Y operations

That would mean actual converting operations X from D1 to their équivalent in D2 though, at which point optimizations that know about all X in D1 wouldn’t be able to operate.

and can analyze both, whereas with (b) there are two independent dialects, each one with a view of only one of the operations (either X or Y).

I was under the impression that an optimization could only operate on ops from a single dialect and not on ops from multiple dialects. But perhaps my assumption is incorrect?

Yes: optimisation are free to operate across dialects.

For example any LLVM aware optimizations could work on a GPU kernel* on the LLVM dialect without understanding the NNVM dialect operations. GPU specific optimization would operate on NVVM and very likely on LLVM dialect operations at the same time.

* actually this isn’t entirely true because of not modeling « convergent » today, but for thé saké of the example we can leave this out.

— 

Mehdi

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/59ef031d-5f98-47d2-89b3-9206e4b03388%40tensorflow.org.

[Sana Damani]

Thank you for clarifying this Mehdi. Dialect-independent optimizations that can operate on mixed-dialect IRs certainly sound powerful, and they handle the concerns I had.

Sana

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/59ef031d-5f98-47d2-89b3-9206e4b03388%40tensorflow.org.

[Alex Zinenko]

This seems settled.

Just to answer the question, the difference between what we have and inheritance, in my understanding of inheritance, is that every operation belongs to a single dialect and so do types. Operations from dialect A can use types from dialect B, but it does not make those types to also belong to A. It does however create a dependence between dialects.

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5039e961-6e5b-4391-a7cb-4aaecec9a465%40tensorflow.org.

[Sana Damani]

Thank you for your explanation Alex. Does this dependence between two dialects allow them to access anything other than types?

Sana

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5039e961-6e5b-4391-a7cb-4aaecec9a465%40tensorflow.org.

[Geoffrey Martin-Noble]

What do you mean by "access"? Dialects can make use of types defined in other dialects and passes can operate on multiple dialects. The IR can contain a mix of dialects. A pass does not belong to a dialect and it can operate on operations and types from multiple dialects. What other part of a dialect would you want your new dialect to access? An op with a custom region in dialect x could have its region contain ops from dialect y, if that's what you're referring to.

I think I probably misled you with my explanation in https://groups.google.com/a/tensorflow.org/d/msg/mlir/4i6LR6fbDvQ/Bwh415SEAAAJ. I was saying that you wouldn't be able to fuse your ops because whatever fusing pass that was already written would probably be operating on standard ops, not because a pass that operated on standard and dialect-specific ops was not possible.

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5ecff2a7-8258-4563-8cf2-5d387b3fb36b%40tensorflow.org.

[Sana Damani]

Thanks Geoffrey, I have a better understanding now.

 

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5ecff2a7-8258-4563-8cf2-5d387b3fb36b%40tensorflow.org.

[Alex Zinenko]

Dialects can be thought of as bags of types, attributes and operations.  They don't know anything about other dialects and are intended to be pluggable in the infrastructure.  The only place where the dependence actually appears is in the build scripts.  I don't think there is a way to know, at runtime, if an operation that belongs to dialect A consumes or produces types that belong to dialect B.

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5ecff2a7-8258-4563-8cf2-5d387b3fb36b%40tensorflow.org.

--

-- Alex

[Sana Damani]

I don't think there is a way to know, at runtime, if an operation that belongs to dialect A consumes or produces types that belong to dialect B.

Hi Alex, could we not use use-def information to determine if an input to an operation that belongs to dialect A was generated by an operation that belongs to dialect B?

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/5ecff2a7-8258-4563-8cf2-5d387b3fb36b%40tensorflow.org.

--

-- Alex

[Mehdi AMINI]

On Tue, Jun 11, 2019 at 11:12 AM Sana Damani <sana....@intel.com> wrote:

I don't think there is a way to know, at runtime, if an operation that belongs to dialect A consumes or produces types that belong to dialect B.

Hi Alex, could we not use use-def information to determine if an input to an operation that belongs to dialect A was generated by an operation that belongs to dialect B?

You can do that, but that does not tell you anything about the actual type of the value :)

I also think that the point was that you can't query at runtime what kind of type would an operation accept types that belong to another dialect.

For instance the NVVM dialect operations are operating on the LLVM dialect types, but this isn't something you can query: the code that manipulate these operations is expected to know.

-- 

Mehdi

 

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/74b7e302-c319-4c11-912e-b66032fafc10%40tensorflow.org.

[Alex Zinenko]

On Tue, Jun 11, 2019 at 8:15 PM Mehdi AMINI <joke...@gmail.com> wrote:

On Tue, Jun 11, 2019 at 11:12 AM Sana Damani <sana....@intel.com> wrote:

I don't think there is a way to know, at runtime, if an operation that belongs to dialect A consumes or produces types that belong to dialect B.

Hi Alex, could we not use use-def information to determine if an input to an operation that belongs to dialect A was generated by an operation that belongs to dialect B?

You can do that, but that does not tell you anything about the actual type of the value :)

Indeed. You can also query what type does that value has, and then what to dialect does that type belong.  However, it will only tell you that a specific value V produced by a specific operation O belonging to dialect D somewhere in the IR belongs to a dialect E.  This does not allow you to conclude that O always produces values of a type that belongs to the dialect E.  Any instance of operation O belongs to dialect D, and this can be checked without actually constructing any IR.  There is no analogy for the types of consumed/produced values. 

 

I also think that the point was that you can't query at runtime what kind of type would an operation accept types that belong to another dialect.

For instance the NVVM dialect operations are operating on the LLVM dialect types, but this isn't something you can query: the code that manipulate these operations is expected to know.

Yes, I think the general practice is to be conservative about unknown operations and do nothing to them.

 

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CANF-O%3DaPPFyCvZp1joiP8MA09rjHD0RTzVXdhLZjuYBEviVL7g%40mail.gmail.com.

--

-- Alex

[Sana Damani]

Would it not be useful to have accepted types as a property of the operation and be able to query this information at runtime?

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/74b7e302-c319-4c11-912e-b66032fafc10%40tensorflow.org.

[Geoffrey Martin-Noble]

The operation has verification to confirm the types it's passed are legal. It might be useful at runtime to know all types an operation accepts, but we haven't needed to so far. What are you trying to achieve?

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/d93b2884-b0cf-457e-b451-00d2ff4dd009%40tensorflow.org.

[Alex Zinenko]

I agree that this may be useful in the long run.  At the same time, we want operations to be as flexible as possible.  Think of a function-call operation: it may take and return values of absolutely any type, even unregistered types it has no knowledge of.  In general, we would need a way to specify constraints on the types that an operation accepts or produces and, even better, a way to infer the type of the result given those of the arguments.  This is the general direction we took with the operation definition syntax -- https://github.com/tensorflow/mlir/blob/6a986290c2848b060aa831dbc94209a9c5495d41/include/mlir/IR/OpBase.td#L168 -- we can specify constraints on types and compose them.  The conceptual problem to solve is the enumeration of types that respect the constraints provided that the type system is intentionally open, so you cannot enumerate all possible types.

If you have a specific usage scenario in mind, this could help us find the better design.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAKeN2efHSOhb-xggLd9aDDa-scU7nrOf9CLhozNnKTCwoCMjkA%40mail.gmail.com.

--

-- Alex

[Sana Damani]

The only use case I can think of is testing the legality of a specific optimization. e.g. does the back-end support the int8 version of a specific fused operation?

Sana

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/d93b2884-b0cf-457e-b451-00d2ff4dd009%40tensorflow.org.

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAKeN2efHSOhb-xggLd9aDDa-scU7nrOf9CLhozNnKTCwoCMjkA%40mail.gmail.com.

--

-- Alex

[Geoffrey Martin-Noble]

Ah I believe the planned approach there is to try it and see if it fails verification :-P

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/083295ed-7d12-48be-bf92-c8c5e1b07b4d%40tensorflow.org.

[Mehdi AMINI]

On Tue, Jun 11, 2019 at 3:21 PM Sana Damani <sana....@intel.com> wrote:

The only use case I can think of is testing the legality of a specific optimization. e.g. does the back-end support the int8 version of a specific fused operation?

It still isn't clear to me how this would work: now the property isn't the one of an operation in a dialect but also contextual (as in the target is looking into restricting the type supported by an operation)?

-- 

Mehdi

 

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/083295ed-7d12-48be-bf92-c8c5e1b07b4d%40tensorflow.org.

[Sana Damani]

Well this is assuming the dialect itself is target-specific (e.g. NVVM for GPUs).

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/083295ed-7d12-48be-bf92-c8c5e1b07b4d%40tensorflow.org.

[Mehdi AMINI]

On Wed, Jun 12, 2019 at 7:02 AM Sana Damani <sana....@intel.com> wrote:

Well this is assuming the dialect itself is target-specific (e.g. NVVM for GPUs).

In this case why would you need a runtime query? You know statically the operations and their constraints.

-- 

Mehdi

 

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/2a6a8e20-130b-4fc3-b3f5-3929f7f7d25e%40tensorflow.org.

[Sana Damani]

That's a good point. I can't really think of any situation where we might need run-time type information.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/2a6a8e20-130b-4fc3-b3f5-3929f7f7d25e%40tensorflow.org.