[LLVMdev] LLVM is doing something a bit weird in this example (which messes up DSA)

[John Criswell]

On 3/31/14, 6:09 PM, Zvonimir Rakamaric wrote:
> Hi all,
>
> I have yet another DSA-related question :), and I would appreciate
> your help. Actually, the following example generates some interesting
> potential issues in the LLVM IR too.
>
> Here is the example in C:
> #define CAS(x,y,z) __atomic_compare_exchange_n(x,&(y),z,true,0,0)
>
> int main() {
>    int *x = 0;
>    int y = 0;
>    int *z = x;
>    CAS(&z,x,&y); // if (z == x) z = &y;
>    assert(*z == y);
>    return 0;
> }
>
> Now, when compiled into LLVM IR 3.4 (with -mem2reg), an interesting
> thing happens in this LLVM IR excerpt:
>    %1 = bitcast i32** %z to i64*
>    %2 = bitcast i32** %x to i64*
>    %3 = bitcast i32** %.atomictmp to i64*
>    %4 = load i64* %2, align 8
>    %5 = load i64* %3, align 8
>    %6 = cmpxchg i64* %1, i64 %4, i64 %5 monotonic
>
> More specifically, there is this %2 bitcast and the subsequent %4 load
> that effectively turned an i32* pointer value into an i64 integer
> value without using ptrtoint instruction.
> My first question is whether that is even allowed in LLVM IR?
> It feels like ptrtoint gets bypassed somehow, which does not seem right.

I believe this optimization is correct (although it obscures 
source-level types information) on systems for which pointers are 64 
bits in size (e.g., x86_64).


>
> Now, if this LLVM IR code is indeed fine, then we have a problem with
> DSA when it gets to this cmpxchg instruction since DSA then does not
> know that the second and third arguments to cmpxchg are in fact
> pointers. Messy stuff...

Have you looked at the local DSGraphs to verify that DSA is not 
inferring the pointer type for the fields accessed by the cmpxchg? I 
would think that DSA can handle this sort of thing, although I can think 
of two reasons that it may not:

a) It may not properly understand the semantics of the cmpxchg 
instruction.  A quick check into the Local.cpp file could confirm this.

b) DSA may be "losing" the pointer through the bitcast.  I think we've 
modified DSA to not do that, but again, it's possible.

Can you verify that DSA is not inferring a link for offset 0 in %1?

-- John T.

>
> Your help would be greatly appreciated...
>
> Thanks!
>
> Cheers,
> -- Zvonimir
>
> --
> http://zvonimir.info
> http://soarlab.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev