Hi, On Fri, 20 Nov 2015, Jeff Law wrote:
> > I'm undecided on whether cs-elim is safe wrt the store speculation vs > > locks concerns raised in the thread discussing Ian's > > noce_can_store_speculate_p, but that's not something we have to consider > > to solve the problem at hand. > I don't think cs-elim is safe WRT locks and such in multi-threaded code. > > In particular it replaces this: > > bb0: > if (cond) goto bb2; else goto bb1; > bb1: > *p = RHS; > bb2: > > with > > bb0: > if (cond) goto bb1; else goto bb2; > bb1: > condtmp' = *p; > bb2: > condtmp = PHI <RHS, condtmp'> > *p = condtmp; It only does so under some conditions, amongst them if it sees a dominating access to the same memory of the same type (load or store) and size. So it doesn't introduce writes on paths that don't already contain a write, and hence are multi-thread safe. Or, at least, that's the intention. > If *p is a shared memory location, then there may be another writer. > If that writer happens to store something in that location after the > load of *p, but before the store to *p, then that store will get lost in > the transformed pseudo code. Due to the above checking, also the first thread must have been an writer so there already are two writers on the same location, and hence a race is pre-existing. It's only when you introduce a write when there was none whatsoever before (perhaps due to conditionals) that you create a new problem. Ciao, Michael.
