Hi,
In [RFC] Assignment tracking: A better way of specifying variable locations in IR I presented a new way to track variable locations in IR. TL;DR, we make better decisions about whether to use a stack-home location or not by connecting assignment markers to stores and then performing an analysis after middle end optimisations have run.
We’re hoping to enable this feature by default very soon. The summary is that there’s an improvement in accuracy and coverage for variable locations at the cost of a compile time regression.
Here’s some important info:
Variable location coverage improvement for a RelWithDebInfo (-O2 -g) build of CTMark:
+==================+========+========+==========+
| CTMark project | AT=off | AT=on | cov gain |
+==================+========+========+==========+
| 7zip-benchmark | 74.166 | 75.213 | 1.04737 |
| bullet | 66.415 | 66.493 | 0.07736 |
| lencod | 54.167 | 56.619 | 2.45203 |
| kc | 82.353 | 82.541 | 0.18814 |
| SPASS | 66.800 | 69.382 | 2.58245 |
| clamscan | 64.302 | 65.713 | 1.41119 |
| consumer-typeset | 42.262 | 51.910 | 9.64797 |
| pairlocalalign | 65.546 | 65.848 | 0.30247 |
| sqlite3 | 69.063 | 69.547 | 0.48381 |
| tramp3d-v4 | 88.143 | 87.583 | -0.56031 |
+------------------+--------+--------+----------+
That’s an average variable location coverage increase of 1.76 (percentage of program covered by variable locations), or 0.974 ignoring consumer-typeset which looks like an outlier. Bear in mind that this number also includes a reduction in coverage as a result of some now-eliminated incorrect locations.
There is a compile time cost for -g builds when the feature is enabled (extra work is done to produce better variable locations). Compile time for -O2-g builds of CTMark looks to increase by around 1%. LTO-g and -O0-g builds have less reasonable performance regressions when the feature is enabled, so I propose the feature is not enabled by default for those cases. This isn’t catastrophic as -O0-g builds get no benefit and LTO reduces the benefit for optimized builds (fewer variables left on the stack).
Due to an issue in LLDB ([lldb] Print command reports incorrect struct field value · Issue #42471 · llvm/llvm-project · GitHub) it may also be worth disabling the feature when -glldb is specified for now.
There are a few minor issues which I’m looking at currently, and some performance improvements are still in review, but overall I think it would be valuable to enable the feature very soon.
You can enable the feature at the moment with -Xclang -fexperimental-assignment-tracking.
Does anyone have any objections or thoughts on this? Please let me know.
Thanks,
Orlando