[llvm-dev] Representations of IR in the output of opt

[Gerolf Hoflehner via llvm-dev]

There is a non-deterministic problem with the uselists. The code causing this is almost identical in the IR and the bc writer. In some invocations of opt the uselists are shuffled in others (same input) they are not. I haven’t nailed the root cause yet. It has the flavor of a stack memory corruption. 
For a quick check that you see the same issue you could disable the shuffle code in the writers.

Gerolf


Sent from my iPhone

> On May 30, 2019, at 1:41 PM, Sébastien Michelland via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello again,
> 
>> It may be desirable to sort the table before writing the bitcode out, adding Peter to the thread for his opinion.
> 
> Thanks for this!
> 
> Now it seems I've been optimistic about this result. I have instrumented the test suite to check it on a wider amount of files and quickly discovered that it fails for larger optimization sequences.
> 
> In particular, the default -O3 set in which I'm interested is not reproduced easily. I'm attaching a script that demonstrates this.
> 
> It contains the extracted -O3 set in two groups, and checks that [opt -debug-pass=Arguments] reports the same sequences when called with -O3 and the individual arguments. If a file name is provided, it also checks that the outputs are the same (or in our case, different).
> 
> Many real files fail to pass this test, for instance bilateral_grid.bc:
> 
> <https://github.com/llvm/llvm-test-suite/blob/master/Bitcode/Benchmarks/Halide/bilateral_grid/bilateral_grid.bc>
> 
> The diffs are very large even in text mode, and include lots of code.
> 
> I'm puzzled again. Any clue on the behavior of opt is very welcome. :)
> 
> Cheers,
> Sébastien Michelland
> <not-associative.sh>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev