[cxx-mem-model] disallow load data races (1 of some)

Jeff Law law@redhat.com
Thu Mar 31 13:32:00 GMT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/31/11 07:26, Richard Guenther wrote:
> On Thu, Mar 31, 2011 at 3:08 PM, Jeff Law <law@redhat.com> wrote:
> On 03/24/11 17:57, Andrew MacLeod wrote:
>>>> My fault for not being specific about it... I tend to just use data race
>>>> as a catch all for all these types of things when talking about them
>>>> with Aldy.
>>>>
>>>> the testcase should have      for (x=0; x< limit; x++)  sum[x] = global;
>>>>     rather than x<5,  so that its not a known loop count.
>>>>
>>>> The hoisted load is then not allowed as it become a speculative load of
>>>> 'global' on the main path which would not otherwise have been there.
>>>> When the value of limit < 0, this can cause a load race detection on
>>>> systems with either a software or hardware data race detector.
> We generally don't allow this kind of code motion anyway -- though it's
> more because we haven't built any kind of analysis to determine that
> this kind of speculative load is often profitable and can't result in a
> fault.
> 
> However, having a switch we can throw to avoid this behaviour (assuming
> we add this kind of speculative code motion one day) is, IMHO, a good thing.
> 
>> If we know the access to global cannot trap I see no reason to disallow
>> speculative reading of it.
Without trip count estimates the speculative read can introduce a
performance regression.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNlIFYAAoJEBRtltQi2kC7+PsH/jRDrhp30ZgRcKctox4/4w46
GBPWsizmDttIg9INfWejX5xvD6wj++qKwBEjD4+5CiDPnjVg6A+5Kr4NrfyQoINx
m/kJHmSlO70jHTkfux24tA+Psyj+eyxEFIsXtntaW06MN0J4umEUceJj1SKygi4Q
qVfzR9q8gqDKZSEaNzDDpuZh8ANGt2Te4aAK27zd1aWImqjNdXJquESnr0i9Wyqo
Q6539rpfemCmSY5dusu0IGUoEWmKqk7EpfJPSsfZgb5E4FgnDMUCclHcNeMQatAC
aDmTVeP/AAtd+9ILwVyu0/j38Es6v5kMUXIRJxhMtjLAIQ6DTSajM7IUmuOs4Lg=
=TF6O
-----END PGP SIGNATURE-----



More information about the Gcc-patches mailing list