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
Improvements to UNOPTFLAT reporting #611
Comments
Original Redmine Comment Good improvements.
|
Original Redmine Comment Thanks for all the comments. Here is what I have done: The reports now match the layout of the Example: lines The option is now --unoptflat-report. I've kept everything optional for now. Corrected the nits. Tidied up commenting of .v test files and renamed .pl files with _bad suffix, since they are intended to fail. I haven't renamed the .v files, since I hope in the future we may be able to automatically fix UNOPTFLAT. I couldn't work out which file was missing a newline at the end of file. The one change I have yet to make is adding the clone() function. I can see how to do this, but conventionally clone() takes no arguments. Which for a graph vertex or edge means it would create a copy of the vertex or edge in the same graph. Yet what I want is to create a copy of the vertex or edge in a different graph. I think there are three options - please let me know which one you think best:
Let me know what you prefer. In the meantime I have updated branch unoptflat at git@github.com:jeremybennett/verilator.git. |
Original Redmine Comment It is fine and correct for clone() to have a V3Graph because that is what the normal constructor requires. Other clones such as in AstNode don't have parameters only because their constructors don't need information about their parent. If you can update that I'm otherwise happy and will merge. |
Original Redmine Comment Took a little longer to do than I thought, but now all in there. Regression tests all pass. I'd appreciate your thoughts on my C++ for implementing the @clone()@ function. It can't be a true copy constructor, because there are some parts of the class we don't want to copy. I would have liked to have something like:
with a derived class then being
The trouble is the type returned by the base class @clone()@ is @V3GraphVertex *@, not @OrderEitherVertex *@. Unlike with a constructor, this explicit calling of a base class method, really doesn't work with functions that return the class as type. So my solution is to separate out into a virtual clone() function which calls the constructor and then calls a separate protected virtual @cloneContents()@ instruction to copy the data. A subclass then just needs to implement a @cloneContents()@ function that calls the base class @cloneContents()@ function, then copies the contents specific to this class. For example:
This achieves what is wanted, but I can't help feeling there is a cleaner way to do this. Please pull the latest version from branch unoptflat at git@github.com:jeremybennett/verilator.git. |
Original Redmine Comment Maybe I'm not understanding the problem properly, but you should be using the constructor to pass the arguments and the return type can vary up the tree and the compiler will work it all out. See how V3OrderGraph.h does it. For example:
Also minor nit, I prefer "Typename* foo" not "Typename * foo" or * then foo with no space. The former is more common in C++ the latter in C. The reason is the pointer is part of the type. Yes, the programmer does need to know though that "Typename* foo, bar" will not make bar a pointer, but that's bad form. |
Original Redmine Comment Is there another rev coming with the clone fixed? |
Original Redmine Comment Hi Wilson, Sorry for the delay - urgent customer work has kept me away from this for over a week. The problem I was trying to get round was cloning parts of the class which are not set in a constructor. I'll add the necessary constructors, so I can use this approach (which will be simpler than adding a cloneContents method). I'll try to get to this later today. Best wishes, Jeremy |
Original Redmine Comment The revised code is pushed to GitHub. I've extended some constructors with optional arguments, which allows the hierarchy of constructors to be used. There is a minor wrinkle, in that some of the intermediate classes are abstract, and thus do not permit a clone function returning a concrete result. This is resolved by requiring the derived class(es) to do the necessary construction (or in one case the derived classes of the derived class). I believe I have turned all @t v@ into @t v@, apologies if I missed any. Please pull the updated code from branch unoptflat at git@github.com:jeremybennett/verilator.git. |
Original Redmine Comment Pushed to git towards 3.846. I made some changes to the clone stuff so the base classes were cleaner, and decided to rename it to --report-unoptflat simply so if we add other reports all the options will be next to each other in the docs. Thanks for the patches! |
Original Redmine Comment In 3.846. |
Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 611 from https://www.veripool.org
Original Date: 2013-02-03
Original Assignee: Jeremy Bennett (@jeremybennett)
I've done a lot of work over last year on large designs where UNOPTFLAT is a recurring problem. Almost always this is due to bit-loops within vectors that can be resolved by splitting the right vector within the loop. Eventually this is something I would like to automate.
In the meantime, I have added some modifications to Verilator, to increase the amount of reporting when this warning occurs. It adds a new flag, @--unoptflat-extra@. If this is specified, each time Verilator encounters UNOPTFLAT, in addition to its standard example loop it will produce:
The vectors identified are strong candidates for splitting to break the loop. The graph may also be of help, although for big designs, it can be very large.
Please pull a patch for this from branch unoptflat at git@github.com:jeremybennett/verilator.git. This includes a number of additional tests which demostrate UNOPTFLAT in various guises, but which are primarily provided to help in future automation of UNOPTFLAT resolution.
The text was updated successfully, but these errors were encountered: