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

[d-bugmail at puremagic.com]

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


David Nadlinger <code at klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code at klickverbot.at


--- Comment #3 from David Nadlinger <code at klickverbot.at> 2012-12-16 02:49:36 PST ---
I'm not sure that this isn't just a GDC bug. Why should status necessarily be
thread-local?

At least in LDC, the parameter to atomicReadUbyte is just an i8 pointer. There
is no reason why it should require any special qualification as
volatile/shared/etc. in order for the compiler to handle it correctly for
codegen _inside_ the function, as its target is simply not known. We will just
emit an LLVM atomic load instruction from that address.

But I'm also not quite sure why the calling code should permit hoisting the
call to that function (resp. the atomic load, after inlining) out of the loop.
You say that "the GCC backend only sees a repeated access to a thread-local
variable" – why should status necessarily be a thread-local variable?
Thread-localness of a class instance (TaskPool in this case) cannot be inferred
from the lack of a shared qualifier on its type in D, as there is __gshared.

As for the general requirements of shared, I'd rather wait until we have a
finished design including an at least somewhat precise spec for that (which is
something of crucial importance when it comes to semantics) before spending
lots of time trying to guess how exactly the requirements will be.

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