8000 [NFC][SYCL] Use visitors to print kernel name type by Fznamznon · Pull Request #2660 · intel/llvm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[NFC][SYCL] Use visitors to print kernel name type #2660

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

Merged
merged 5 commits into from
Oct 21, 2020

Conversation

Fznamznon
Copy link
Contributor

This is the part of integration header generator refactoring to make
it use clang visitors and simplify the code.

This is the part of integration header generator refactoring to make
it use clang visitors and simplify the code.
@Fznamznon
Copy link
Contributor Author

Hi, I have a note for reviewers, there is a couple of questions over the code. The first one is about printing of "class" keyword before names of classes which don't belong to any namespace. I saved the old behavior, but it seems that if we don't print it resulting integration header is still valid.
The second question is about destructor of the new visitor, I noticed that there are a lot of calls to emitWithoutAnonNamespaces functions and they all do the same thing, so I wanted to make only one call of this function and put it into destructor. Now it requires to destruct visitor object so it "flushes" its internal buffer to output. If you don't find this solution good, I can return to several calls to emitWithoutAnonNamespaces function or for example define some "flush" function which will remove anon namespaces from internal buffer and write result to the output.
Please let me know your thoughts.

Copy link
Contributor
@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comments :)

@erichkeane
Copy link
Contributor

Hi, I have a note for reviewers, there is a couple of questions over the code. The first one is about printing of "class" keyword before names of classes which don't belong to any namespace. I saved the old behavior, but it seems that if we don't print it resulting integration header is still valid.
The second question is about destructor of the new visitor, I noticed that there are a lot of calls to emitWithoutAnonNamespaces functions and they all do the same thing, so I wanted to make only one call of this function and put it into destructor. Now it requires to destruct visitor object so it "flushes" its internal buffer to output. If you don't find this solution good, I can return to several calls to emitWithoutAnonNamespaces function or for example define some "flush" function which will remove anon namespaces from internal buffer and write result to the output.
Please let me know your thoughts.

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

As far as the 'class' keyword, I'd prefer it not be there if not necessary. However, this patch is sufficiently large of an improvement over the old code that I'd think an investigation into it could happen at a later date if you so wished.

@Fznamznon
Copy link
Contributor Author

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

As far as the 'class' keyword, I'd prefer it not be there if not necessary. However, this patch is sufficiently large of an improvement over the old code that I'd think an investigation into it could happen at a later date if you so wished.

Thanks! Then I'll add 'flush' function and I think I'll leave 'class' keyword investigation to the next patches to keep this one smaller and NFC.

@elizabethandrews
Copy link
Contributor

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

@erichkeane Can you elaborate why? We have a couple of places in SemaSYCL where we use destructors for different tasks. Why is it weird to use it to emit output?

Anyway, other than comments by Erich, the patch looks good to me. Thanks!

@erichkeane
Copy link
Contributor

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

@erichkeane Can you elaborate why? We have a couple of places in SemaSYCL where we use destructors for different tasks. Why is it weird to use it to emit output?

Anyway, other than comments by Erich, the patch looks good to me. Thanks!

Actually, in reprospect now that I see more of what it is doing, I don't think the destructor is an inappropriate place for it, unless further patches show a reason why it wouldn't be required. But having the destructor do the 'commit to file' part is perfectly fine. I think it actually works well there. In general, my problem is with the emitWithoutAnonNamespaces function in itself, it seems that should be a part of the printing policy or something.

@Fznamznon
Copy link
Contributor Author
Fznamznon commented Oct 20, 2020

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

@erichkeane Can you elaborate why? We have a couple of places in SemaSYCL where we use destructors for different tasks. Why is it weird to use it to emit output?
Anyway, other than comments by Erich, the patch looks good to me. Thanks!

Actually, in reprospect now that I see more of what it is doing, I don't think the destructor is an inappropriate place for it, unless further patches show a reason why it wouldn't be required. But having the destructor do the 'commit to file' part is perfectly fine. I think it actually works well there. In general, my problem is with the emitWithoutAnonNamespaces function in itself, it seems that should be a part of the printing policy or something.

I was able to stop using emitWithoutAnonNamespaces inside a new visitor just by using PrintingPolicy properly. Then I could actually stop using internal buffer and we won't need custom destructor or flush function.

@erichkeane
Copy link
Contributor

I think the 'flush' function is a good idea then. The destructor seems in retrospect like an odd place for that.

@erichkeane Can you elaborate why? We have a couple of places in SemaSYCL where we use destructors for different tasks. Why is it weird to use it to emit output?
Anyway, other than comments by Erich, the patch looks good to me. Thanks!

Actually, in reprospect now that I see more of what it is doing, I don't think the destructor is an inappropriate place for it, unless further patches show a reason why it wouldn't be required. But having the destructor do the 'commit to file' part is perfectly fine. I think it actually works well there. In general, my problem is with the emitWithoutAnonNamespaces function in itself, it seems that should be a part of the printing policy or something.

I was able to stop using emitWithoutAnonNamespaces inside a new visitor just by using PrintingPolicy properly. Then I could actually stop using internal buffer and we won't need custom destructor or flush function.

even better!

erichkeane
erichkeane previously approved these changes Oct 20, 2020
Copy link
Contributor
@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

premanandrao
premanandrao previously approved these changes Oct 20, 2020
@bader bader merged commit 44354f0 into intel:sycl Oct 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0