On Thu, 2012-05-03 at 11:44 -0600, Jeff Law wrote:
> On 05/03/2012 10:47 AM, William J. Schmidt wrote:
> > Yes and no. What's important is that you don't want to introduce page
> > faults (or less urgently, cache misses) by speculating the load. So the
> > patch is currently extremely constrained, and likely will always stay
> > that way. Only fields that are pointers and that are strictly adjacent
> > are hoisted, and only if they're in the same 16-byte block. (The number
> > 16 is a parameter that can be adjusted.)
> > Hopefully I didn't miss your point -- let me know if I did and I'll try
> > again. :)
> You missed the point :-)
> Under the C++11 memory model you can't introduce new data races on
> objects which might be visible to multiple threads. This requirement
> can restrict speculation in many cases. Furthermore, it sounds like C11
> will have similar constraints.
> I believe there's a wiki page which touches on these kinds of issues.
> That doesn't mean we can't ever do the optimization, just that we have
> to be more careful than we have in the past when mucking around with
> memory optimizations.
OK, thanks! Looks like I have some reading to do about the new memory
However, from the wiki page I see: "A speculative load which has its
results thrown away are considered to not have changed the semantics of
the program, and are therefore allowed." That seems to cover the case
here: the load is hoisted, but if the path where it was originally
loaded is not executed, its result is discarded.
If needed, though, what flags/detection mechanisms are available for
determining that the load speculation should be disabled?