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

verilator runs out of memory at gateAll #1260

Closed
veripoolbot opened this issue Jan 12, 2018 · 5 comments
Closed

verilator runs out of memory at gateAll #1260

veripoolbot opened this issue Jan 12, 2018 · 5 comments
Assignees

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Jan 12, 2018


Author Name: Alex Solomatnikov
Original Redmine Issue: 1260 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


verilator consumes ~100 GB of memory at gateAll stage and runs out of memory eventually:

(gdb) bt
#0  0x0000000000459fb4 in V3GraphEdge::top (this=0x33c409790) at ../V3Graph.h:278
#1  0x0000000000541240 in GateVisitor::optimizeSignals (this=0x7fffffffdaa0, allowMultiIn=true) at ../V3Gate.cpp:583
#2  0x00000000005459b1 in GateVisitor::visit (this=0x7fffffffdaa0, nodep=0xae9c20) at ../V3Gate.cpp:394
#3  0x0000000000409bf2 in AstNetlist::accept (this=0xae9c20, v=...) at ../V3AstNodes.h:5552
#4  0x0000000000546692 in GateVisitor::GateVisitor (this=0x7fffffffdaa0, nodep=0xae9c20) at ../V3Gate.cpp:529
#5  0x00000000005436b3 in V3Gate::gateAll (nodep=0xae9c20) at ../V3Gate.cpp:1493
#6  0x00000000004063d7 in process () at ../Verilator.cpp:351
#7  0x00000000004071a2 in main (argc=26, argv=0x7fffffffe1c8, env=0x7fffffffe2a0) at ../Verilator.cpp:603

It looks like copy constructor is creating another copy of the graph and at that point it runs out of memory:

    V3GraphVertex*	top() const { return m_top; }

It looks like verilator is stuck at this point for several minutes before running out of memory.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 17, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-17T00:31:54Z


Believable, but will need a testcase (or ideally your own debugging) to figure out why it's so bad.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 22, 2018


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2018-01-22T23:44:55Z


The testcase is ready but it is large: ~.5.5 MB in compressed form. What's the best way to send it?

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 23, 2018


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2018-01-23T01:24:38Z


BTW, the same testcase compiles with -Og -Wno-fatal, then clang++ compiles C++

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 27, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-27T20:06:55Z


The code has thousands of lines similar to this

assign FOO_1 = (BAR == 13'h101) ? 64'h0 : FOO_0;
assign FOO_2 = (BAR == 13'h102) ? 64'h0 : FOO_1;
assign FOO_3 = (BAR == 13'h103) ? 64'h0 : FOO_2;

Obviously they are machine generated. The optimizer is going crazy optimizing them. I would recommend creating more sane code, it will translate and run a lot faster. But anyhow...

Fixed in git to stop optimizing at some point, and added --gate-stmts parameter to tune this.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 2, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-02-02T01:16:41Z


In 3.920.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.