Remaining malloc to new

[jmah76]

Description

Changed remaining malloc/calloc/reallocs to new.

How Has This Been Tested?

Passes all CI tests.

Types of changes

• [ X] Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[vaughnbetz]

Getting close: please confirm all review suggestions addressed (and push latest code), resolve conflicts, and upload the latest QoR spreadsheet and summarize. Then we can merge.

[vaughnbetz]

Looks like there are a few errors in the QoR tests -- I think results were not generated for a few runs, like:
00:13:31 | Warning: task includes result for arch.timing.xml/picosoc_basys3_full_100.eblif missing in golden results
00:13:31 | Warning: task includes result for arch.timing.xml/picosoc_basys3_full_50.eblif missing in golden results
00:13:31 | Warning: task includes result for arch.timing.xml/linux_arty.eblif missing in golden results
00:13:31 | Warning: task includes result for arch.timing.xml/minilitex_arty.eblif missing in golden results
00:13:31 | Warning: task includes result for arch.timing.xml/minilitex_ddr_arty.eblif missing in golden results
00:13:31 | Warning: task includes result for arch.timing.xml/minilitex_ddr_eth_arty.eblif missing in golden results

[vaughnbetz]

@jmah76 : can you take a look? Not sure why warnings passed on this one, and not on Sebastian's PR (maybe he needs to update the branch)?

[vaughnbetz]

6 failures (missing QoR data?) in nightly_test1. One slightly higher vpr_max_mem on a small design in nightly_test2:
stratixiv_arch.timing.xml/murax_stratixiv_arch_timing.blif/common max_vpr_mem relative value 1.202197661475418 outside of range [0.8,1.2], above absolute threshold 102400.0 and not equal to golden value: 812136.0

The nightly test 2 failure is spurious; you can just update the golden results to have the new memory footprint number (it's not a big change -- just slightly more than the allowed 20%).

[jmah76]

It's not missing QoR data-- one of the ASSERTs in bucket.cpp is failing because of the shift from using a vector to temporarily store the heap_ array for the resize to changing the heap_ array to a vector. I don't know why this is happening.

[vaughnbetz]

If you can't sort it you can revert that one (just go back). If you look at it closely hopefully you can figure out the bug, but if not, revert.

The bucket heap is only used for the Artix7 (Symbiflow) compiles, so it's not really the default flow.

[jmah76]

I reverted only bucket.cpp back, and vtr_reg_nightly 1 seems to be working now. If it's okay, to fix vtr_neg_nightly 2, I'll do what you suggested here:

The nightly test 2 failure is spurious; you can just update the golden results to have the new memory footprint number (it's not a big change -- just slightly more than the allowed 20%).

[vaughnbetz]

Yup, that's fine.

[vaughnbetz]

CI passed. @jmah76 : can you attach the QoR comparison data so we see all is well (should be, but I'd like to check). There was some earlier data attached but I believe it had parse errors and wasn't correct.

[vaughnbetz]

QoR generally looks good (unchanged critical paths, wirelength etc. on the vtr benchmarks, and roughly tied cpu time). Memory footprint is unchanged on the larger designs, but goes up by 1.6x or even 2.2x on the smaller designs; suspect some small data structures is consuming more memory due to being turned into a vector but it has no impact on larger designs since not dominant / at peak.

To be careful @jmah76 will attach the vtr QoR spreadsheet and run and attach the Titan one.

[jmah76]

@vaughnbetz Full Titan QoR results are on my wiki. Nothing looks concerning...

[jmah76]

Here's the vtr QoR chain comparison:

Full on my wiki.

[vaughnbetz]

Thanks. Looks good, so merging.