Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Edge linetype customization #119

Open
Hakan-Eyilmez opened this issue Aug 8, 2024 · 4 comments
Open

[Feature Request] Edge linetype customization #119

Hakan-Eyilmez opened this issue Aug 8, 2024 · 4 comments
Assignees
Labels
stat:awaiting model-navigator The issue is actively being worked on by our navigators type:feature Feature requests

Comments

@Hakan-Eyilmez
Copy link

Someone already asked for a feature modifying the colour of edges ([Feature Request] Edge styling #66 ). In addition I wanted to ask, if it is possible to add a feature, allowing the user to use different types of edges? It would be quite useful representing different types of dependencies. For example in MLIR:

This is the code given to my adapter:
grafik

And this is the generated graph:
grafik

As you can see, both the bufferization.clone and the if_else do not share a dependency, but the flow of the code is still important, which could be represented with a different type of edges.

@pkgoogle
Copy link
Contributor

pkgoogle commented Aug 8, 2024

Hi @Hakan-Eyilmez, we probably could but I'm wondering how useful this is. arg%0 is leading to the block body, both parts of the block body are dependent on it, I feel like the above more or less represents that visually well .... in your ideal state how would these edges look?

@pkgoogle pkgoogle added type:feature Feature requests status:awaiting user response This label needs to be added to stale issues and PRs. status:more data needed This label needs to be added to stale issues and PRs. labels Aug 8, 2024
@Hakan-Eyilmez
Copy link
Author

Hi @pkgoogle, apologies for the confusion. You're correct that arg%0 leads to the block body, and both parts of the block body depend on it. This aspect is accurately represented in the model. However, the time dependency is not depicted here. The if_else block should occur after bufferization.clone but before func.return, which is not shown in the current model.

The ideal representation would resemble the one above, but with additional edges indicating the time dependencies. For instance, a dashed line could connect bufferization.clone to if_else, and further dashed lines could link the two regions to func.return.

If this is still unclear, I can consult my supervisor to provide a better example to illustrate the concept.

@Hakan-Eyilmez
Copy link
Author

Here is another example:

grafik

grafik

In this case, the operand %0 is allocated in memory, used in test.op_norm, and then deallocated. It's crucial that these operations occur in this specific order. However, this sequence isn't clearly visible in the graph.

Ideally, the graph should include edges that illustrate the time dependencies between these operations. Like this:
grafik

@pkgoogle
Copy link
Contributor

Hi @Hakan-Eyilmez, Ok that makes more sense. Sequential dependency for graphs which represent programs which have to execute sequentially makes sense... the only concern in my head is we don't want to enforce a dependency that's not really there so that the representation can show parallelizability (for general cases or arbitrary ML programs). In both your cases though, it seems like we are missing that dependency.

@jinjingforever, can you take a look on how we can implement something like this? Thanks.

Hakan feel free to add any more information if you think I didn't understand it correctly.

@pkgoogle pkgoogle added stat:awaiting model-navigator The issue is actively being worked on by our navigators and removed status:awaiting user response This label needs to be added to stale issues and PRs. status:more data needed This label needs to be added to stale issues and PRs. labels Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stat:awaiting model-navigator The issue is actively being worked on by our navigators type:feature Feature requests
Projects
None yet
Development

No branches or pull requests

3 participants