One could avoid adding complexity to the store queue by using an external filter. Hits in the filter could snoop the store queue at a lower priority than internal load and store operations or simply abort the transaction (even if the address is not in the store queue). (Replicating the store queue address fields would effectively be generating a perfect filter and could be less risky than sharing the store queue.) One might also be able to exploit the cache (and miss status handling registers, if they are snooped) to partially filter accesses (Since this could generate false positives--a cache hit that is not a LSQ hit--and false negatives--a cache miss that is a LSQ hit--, some additional handling would be desirable.).

It might also be noted that the mechanism to support cache-based transactional memory could also be used to extend speculation depth. A checkpoint register set could be provided to retain register values for a potential rollback. (This register set could aggressively support banking and use shared read-write ports. It could even be relatively slow compared to the main register set. Any rollback might be assumed to be a slow and hopefully rare event anyway.)