<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 27, 2019 at 1:12 PM Sébastien Michelland <<a href="mailto:sebastien.michelland@ens-lyon.fr">sebastien.michelland@ens-lyon.fr</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 Mehdi,<br>
<br>
Thank you for mentioning this tool, I was looking for something like <br>
this. By default the analyzer produces identical output on both files, <br>
but a complete -dump shows that the storage order of the symbol table is <br>
different.<br></blockquote><div><br></div><div>Thanks for the update!</div><div>It may be desirable to sort the table before writing the bitcode out, adding Peter to the thread for his opinion.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><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">
<br>
This would explain why text files are not affected: the symbols are used <br>
directly in text form so there is no need for this table.<br>
<br>
I suppose that settles the question of where. Out of curiosity, I'd like <br>
to know if there is a way to order the table in a canonical form. I <br>
found -preserve-bc-uselistorder which makes more sense (and seems to <br>
correspond because the table lists all uses of each symbol), but no luck <br>
yet.<br>
<br>
At least now I'm sure that there is no semantic difference between the <br>
programs so it's a great help. :D<br>
<br>
Thanks,<br>
Sébastien Michelland<br>
<br>
On 5/27/19 1:48 PM, Mehdi AMINI wrote:<br>
> Hi,<br>
> <br>
> I would give try to run llvm-bcanalyzer on these bc files, this may help <br>
> to understand where the discrepancy is coming from.<br>
> <br>
> Best,<br>
> <br>
> -- <br>
> Mehdi<br>
> <br>
> <br>
> On Mon, May 27, 2019 at 10:42 AM Sébastien Michelland via llvm-dev <br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
> <br>
> 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<br>
> files? It's off by default because the output tends to be sort of<br>
> 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><br>
> <mailto:<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> <mailto:<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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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> <mailto:<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> <mailto:<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>
</blockquote></div></div>