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

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri May 24 14:32:17 PDT 2019


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.

-Eli

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of S├ębastien
> Michelland via llvm-dev
> Sent: Friday, May 24, 2019 12:53 PM
> To: llvm-dev at lists.llvm.org
> Subject: [EXT] [llvm-dev] Representations of IR in the output of opt
> 
> Hi LLVM,
> 
> I'm currently setting up some tools to investigate the influence of the
> order of optimization passes on the performance of compiled programs
> -nothing exceptional here.
> 
> I noticed something inconvenient with opt, namely that splitting a call
> does not always give the same output:
> 
> % llvm-stress > stress.ll
> % opt -dse -verify -dce stress.ll -o stress-1.bc
> % opt -dse stress.ll | opt -dce -o stress-2.bc
> % diff stress-{1,2}.bc
> Binary files stress-1.bc and stress-2.bc differ
> 
> The difference seems meaningful; it's ~180 bytes out of ~1400 bytes of
> output in my random case. I can't decode it however, because
> disassembling the bytecode produces identical text files, even with
> annotations. (!)
> 
> I made sure that the sequence for [-dse -verify -dce] is the
> concatenation of the individual sequences; this falls in place naturally
> because -dce has no dependencies. The verifier pass helps make two
> function pass managers, just in case.
> 
> Now if I do the same thing but staying in text format, I get the same IR
> (up to module name):
> 
> % opt -S -dse -verify -dce stress.ll -o stress-1.ll
> % opt -S -dse stress.ll | opt -S -dce -o stress-2.ll
> % diff -y --suppress-common-lines stress-{1,2}.ll
> ; ModuleID = 'stress.ll'	|	; ModuleID = '<stdin>'
> 
> Is there a specific behavior of opt that could explain this situation?
> What kind of difference could there be in the bytecode files that is
> lost in translation to text format ?
> 
> Cheers,
> S├ębastien Michelland
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list