On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > Richard Guenther wrote: >> >> On Thu, May 6, 2010 at 5:50 PM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >> >>> >>> First let me say that the C++ memory model is crap when it >>> forces data-races to be avoided for unannotated data like >>> the examples for packed data. >>> > > And it isn't consistent across the board, since neighbouring bits normally > don't qualify and can introduce data races. I don't like it when a solution > has exceptions like that. It is what it is however, and last I heard the > plan was for C to adopt the changes as well.
I would have hoped that only data races between independent objects are covered, thus tmp = a.i; b.j = tmp; would qualify as a load of a and a store to b as far as dependencies are concerned. That would have been consistent with the exceptions for bitfields and much more friendly to architectures with weak support for unaligned accesses. >>> >>> Well, I hope that instead of just disabling optimizations you >>> will help to improve their implementation to be able to optimize >>> in a conformant manner. >>> > > I don't want to disable any more than required. SSA names aren't affected > since they are local variables only, its only operations on shared memory, > and I am hopeful that I can minimize the restrictions placed on them. Some > will be more interesting than others... like CSE... you can still perform > CSE on a global as long as you don't introduce a NEW load on some execution > path that didn't have before. What fun. I don't understand that restriction anyway - how can an extra load cause a data-race if the result is only used when it was used before? (You'd need to disable PPRE and GCSE completely if that's really a problem) Thus, if (p) tmp = load; ... if (q) use tmp; how can transforming that to tmp = load; ... if (q) use tmp; ever cause a problem? >> And btw, if you are thinking on how to represent the extra >> data-dependencies required for the consistency models think >> of how to extend whatever you need in infrastructure for that >> to also allow FENV dependencies - it's a quite similar problem >> (FENV query/set are the atomic operations, usual arithmetic >> is what the dependency is to). It's completely non-trivial >> (because it's scalar code, not memory accesses). For >> atomics you should be able to just massage the alias-oracle >> data-dependence routines (maybe). >> > > That's what I'm hoping actually.. We'll see. Richard. > Andrew. >
