In the dynInst destructor. This is what's done for regular loads and stores too. It has to belong to the instruction and not an individual access since the same memory may be filled by two accesses and can't be freed in two pieces. I definitely agree that it wasn't straightforward finding where it gets deleted.

You were on track asking about a memory leak, though. I turns out this patch was leaking sender state objects, and because those have a DynInstPtr to the instruction they go with, those were building up and eventually pushed O3 past its limit. This would happen after about 1500 stores to memory mapped registers, so not for a long time. I think I was also leaking packets and request objects. A new version will be uploaded once I've done a little more testing.

I think mostly being careful, but it's easy to avoid building that sort of restriction into the CPU especially since it doesn't apply for regular accesses. I'm not really happy having all that code in a .hh, but it technically is if it's in impl.hh too, and I don't want to chop holes in the middle of those functions if it doesn't really buy anything. I think that's an unfortunate side effect of how much we use templating in O3.