[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