[Issue 9163] std.parallelism broken with extensive optimizations (gdc)

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Dec 16 08:27:35 PST 2012


http://d.puremagic.com/issues/show_bug.cgi?id=9163



--- Comment #11 from Iain Buclaw <ibuclaw at ubuntu.com> 2012-12-16 08:27:35 PST ---
(In reply to comment #10)
> (In reply to comment #3)
> > I'm not sure that this isn't just a GDC bug. Why should status necessarily be
> > thread-local?
> 
> Maybe my conclusions were premature, but according to TDPL chapter 13.12.1 page
> 414: "The compiler optimizes code using non-shared data to the maximum, in full
> confidence that no other thread can ever access it, and only tiptoes around
> shared data".
> 
> The status field is not TLS data as it's not a static field, but it's instance
> data and to my understanding if the class instance isn't marked as shared and
> the field isn't shared the compiler is allowed to assume that only one thread
> can access that data.
> 
> And if the compiler assumes status can only be accessed from one thread and
> "atomicReadUbyte" is inferred as pure, that would lead to this wrong behavior.
> 
> You've got a point that this can't work for __gshared, so I'm not really sure
> what to do about this.
> 
> So is it always invalid to optimize this code in D?
> ---------------------------------------
> pure bool checkFlag(const ref bool a)
> {
> 
> }
> 
> class A
> {
>     bool flag;
> 
>     void test()
>     {
>         while(true)
>         {
>             if(checkFlag(flag)) //Can this check be moved out of the loop
>                 return;
>         }
>     }
> }
> --------------------------------------
> 
> (In reply to comment #2)
> > 
> > I don't think the use of volatile statements/variables may help here...
> 
> wouldn't status as a volatile field signal to the compiler that it's value
> might change between calls to "atomicReadUbyte" and therefore prevent this
> optimization?

atomicReadUbyte isn't pure, but it is inlined.  Leaving atomicLoad as the
culprit.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list