[LLVMbugs] [Bug 4336] New: Iterating over use-def chains doesn' t seem to be deterministic.

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=4336

           Summary: Iterating over use-def chains doesn't seem to be
                    deterministic.
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jlerouge at apple.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=3069)
 --> (http://llvm.org/bugs/attachment.cgi?id=3069)
Pass to print use-def chains.

Hello,

It seems like iterating over use-def chains is not deterministic. It seems uses
are not always stored in the same order.

The attached patch adds a pass that iterates over the use-def chains, printing
all the instructions in the file "usedef.txt0".

By modifying opt command line, the order in which values are printed is
sometimes different.

Example:

$ ../Debug/bin/opt --load LLVMHello.dylib --load LLVMUseDef.dylib -checkusedef
./MultiSource/Benchmarks/ASCI_Purple/SMG2000/Output/random.bc >/dev/null
$ md5 usedef.txt0 
MD5 (usedef.txt0) = 39fbfb368fc1857d790072a16839124f

$ ../Debug/bin/opt --load LLVMUseDef.dylib -checkusedef
./MultiSource/Benchmarks/ASCI_Purple/SMG2000/Output/random.bc >/dev/null
$ md5 usedef.txt0 
MD5 (usedef.txt0) = 3f79a6ff1668d640f456484d588dfc2d

So, in this case, loading the Hello dylib seems to be enough to expose the non
determinism, even though the hello pass doesn't even run.

In this case, the diff is in the order in which uses for a global are showed:
 diff -u ref1.txt usedef.txt0
--- ref1.txt    2009-06-05 17:51:48.000000000 -0700
+++ usedef.txt0 2009-06-05 17:51:57.000000000 -0700
@@ -1,14 +1,14 @@
 @Seed = internal global i32 13579              ; <i32*> [#uses=4]

 Use Begin:
-       store i32 %3, i32* @Seed, align 4
-
        %4 = load i32* @Seed, align 4           ; <i32> [#uses=1]

        store i32 %3, i32* @Seed, align 4

        %1 = load i32* @Seed, align 4           ; <i32> [#uses=1]

+       store i32 %3, i32* @Seed, align 4
+
 Use End:


I found that from all the bc files in the llvm-test build,
./MultiSource/Benchmarks/ASCI_Purple/random.bc was the smallest one to
reproduce the problem on my machine (Leopard 10.5.7, LLVM svn r72977).

The problem also seems to happen with LLVM 2.5.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.