<div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><div>I would give try to run llvm-bcanalyzer on these bc files, this may help to understand where the discrepancy is coming from.</div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 27, 2019 at 10:42 AM Sébastien Michelland via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Eli,<br>
<br>
Unfortunately the differences remain, I do not observe a significant <br>
change in the output besides the fact that it's random.<br>
<br>
I noticed that running opt without options on the random file changes <br>
the order of references in the predecessors of basic blocks (sample <br>
below). Further invocations of opt are idempotent.<br>
<br>
I don't know of this information is stored in the bytecode file as well.<br>
<br>
< ; preds = %CF, %CF80, %CF78<br>
 > ; preds = %CF80, %CF, %CF78<br>
<br>
FWIW, the conflicting section of the bytecode file is likely not a <br>
permutation because the byte patterns don't match (some of the btte <br>
values of stress-1.bc are not present in stress-2.bc).<br>
<br>
Thanks for your help :)<br>
Sébastien Michelland<br>
<br>
On 5/24/19 5:32 PM, Eli Friedman wrote:<br>
> Are you passing -preserve-ll-uselistorder when you create the .ll files?  It's off by default because the output tends to be sort of unreadable, but it could explain some of the differences you're seeing.<br>
> <br>
> -Eli<br>
> <br>
>> -----Original Message-----<br>
>> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Sébastien<br>
>> Michelland via llvm-dev<br>
>> Sent: Friday, May 24, 2019 12:53 PM<br>
>> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> Subject: [EXT] [llvm-dev] Representations of IR in the output of opt<br>
>><br>
>> Hi LLVM,<br>
>><br>
>> I'm currently setting up some tools to investigate the influence of the<br>
>> order of optimization passes on the performance of compiled programs<br>
>> -nothing exceptional here.<br>
>><br>
>> I noticed something inconvenient with opt, namely that splitting a call<br>
>> does not always give the same output:<br>
>><br>
>> % llvm-stress > stress.ll<br>
>> % opt -dse -verify -dce stress.ll -o stress-1.bc<br>
>> % opt -dse stress.ll | opt -dce -o stress-2.bc<br>
>> % diff stress-{1,2}.bc<br>
>> Binary files stress-1.bc and stress-2.bc differ<br>
>><br>
>> The difference seems meaningful; it's ~180 bytes out of ~1400 bytes of<br>
>> output in my random case. I can't decode it however, because<br>
>> disassembling the bytecode produces identical text files, even with<br>
>> annotations. (!)<br>
>><br>
>> I made sure that the sequence for [-dse -verify -dce] is the<br>
>> concatenation of the individual sequences; this falls in place naturally<br>
>> because -dce has no dependencies. The verifier pass helps make two<br>
>> function pass managers, just in case.<br>
>><br>
>> Now if I do the same thing but staying in text format, I get the same IR<br>
>> (up to module name):<br>
>><br>
>> % opt -S -dse -verify -dce stress.ll -o stress-1.ll<br>
>> % opt -S -dse stress.ll | opt -S -dce -o stress-2.ll<br>
>> % diff -y --suppress-common-lines stress-{1,2}.ll<br>
>> ; ModuleID = 'stress.ll'     |       ; ModuleID = '<stdin>'<br>
>><br>
>> Is there a specific behavior of opt that could explain this situation?<br>
>> What kind of difference could there be in the bytecode files that is<br>
>> lost in translation to text format ?<br>
>><br>
>> Cheers,<br>
>> Sébastien Michelland<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>