Observe that v15/v24 and v18/v26 certainly look ripe for CSE.
Rolling back the prohibition on CSEing memory values would require care, though, since that helped a lot with CSE toolspeed problems. Continuing to prohibit CSE of calls might be a workable middle ground.
Our calling convention allows callees to modify their input args on the stack. So I don't think you can CSE v15 & v24, as the first call may modify what v15 put on the stack.
We could change the calling convention, of course. I don't think many callees rely on this ability. But nonetheless it's not a trivial change.
Sorry, I was misinterpreting what you were suggesting. The calls are in different branches, not in serial.
Yes, we could CSE those writes. We haven't been CSEing any pair where one instance does not dominate the other (memory type or otherwise). In general, this is to avoid putting work at the dominator that doesn't need to be done on some path out of the dominator. But when that work needs to be done on every path out of that dominator, we could move the values up with no chance of doing unneeded work.