[llvm-commits] patch: CXAGuardElimination pass.

[Eli Friedman]

On Tue, May 26, 2009 at 7:06 AM, Luke Dalessandro
<luked at cs.rochester.edu> wrote:
> Nick Lewycky wrote:
>> Eli Friedman wrote:
>>> On Mon, May 25, 2009 at 5:17 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>>>> Eli Friedman wrote:
>>>>> On Mon, May 25, 2009 at 3:59 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>
> [cut]
>
>>>>> Ooh, that's right.  Actually, it gets nastier than that: suppose
>>>>> something like the following:
>>>>>
>>>>> static int gval1 = 1;
>>>>> int gval2 = 1;
>>>>> struct A { A() { if (gval1) { printf("%d\n", gval2); } };
>>>>> void a() { static A x(); gval2 = 0;}
>>>>> void b() { a(); }
>>>>> void c() { gval1 = 0; a(); }
>>>>>
>>>>> Then suppose b() and c() are called at the same time on separate
>>>>> threads, and we've inlined/optimized everything; if the guard is
>>>>> removed from c(), we can end up printing out "0", which shouldn't be
>>>>> possible because setting gval2 to zero only happens after the
>>>>> constructor for A finishes.
>>>>>
>>>> Right. deadGuardElim checks for memory *reads* as well as writes and
>>>> unwinds in order to prevent this sort of thing from happening.
>>>>
>>> If a() gets inlined into c(), the load inside A() of gval1 can be
>>> eliminated; I'm not sure if we do that particular optimization at the
>>> moment, though.
>
> This example has data races on gval1 and gval2. The LLVM VM doesn't have
> a memory model as far as I know, which basically means that all sorts of
> crazy things are allowed to happen to this code. Printing out 0 is
> probably fine. Even in something like the Java Memory Model printing out
> 0 is fine, given the raciness of the code.

There is no race on gval2: both threads only set gval2 after "static A
x()" is fully constructed, and we don't care about the value at that
point.  The race of gval1 is irrelevant to the point; I left out
synchronization for it to simplify the example.

-Eli