Currently we insert write barriers in the front end. Once https://golang.org/cl/31131 is in, we'll insert them in the front end and then remove some of them in the back end. This seems rather circuitous, but is necessary in the current structure because the front end has only partial information and has to guess at what the back end will do and be conservative.
We should switch to doing all write barrier insertion in the back end. That is, pass things through as regular assignments and stores until late in SSA (before lowering), and only then determine whether the write needs write barriers. This should have several advantages:
- We can be less conservative, since we have more information. For example, the new removal pass detects write barriers to the local stack frame. The front end tries to figure this out, but isn't always successful. The back end knows.
- We can do more sophisticated analysis. For example, basic flow analysis would make it possible to eliminate many write barriers with the hybrid barrier, but is too hard to do correctly in the front end.
- I suspect several of the funny write barrier cases in the front end around things like append would fall out naturally.
- It just makes sense.
/cc @cherrymui @randall77
Currently we insert write barriers in the front end. Once https://golang.org/cl/31131 is in, we'll insert them in the front end and then remove some of them in the back end. This seems rather circuitous, but is necessary in the current structure because the front end has only partial information and has to guess at what the back end will do and be conservative.
We should switch to doing all write barrier insertion in the back end. That is, pass things through as regular assignments and stores until late in SSA (before lowering), and only then determine whether the write needs write barriers. This should have several advantages:
/cc @cherrymui @randall77