search for: uselistorder

Hello, I want to ask if incorrect serialization of a constant's use-list order is considered as a bug. While compiling some programs with clang -c -emit-llvm -O2 -g I noticed that for many of the bitcode files the verify-uselistorder tool terminates with output *** verify-uselistorder *** verify bitcode LLVM ERROR: use-list order changed where the mismatch is always for the constant i64 0. This happens both with version 5.0.1 and 6.0 RC3 of LLVM and clang. I managed to trigger this behavior with the following reduced test-cas...

...g removing these 5 binaries from 5.0.2-rc1 would have saved over a hundred megabytes in uncompressed space for macOS users: Binary name | Size in megabytes -------------------------------------------- clang-check: 54.6725 llvm-c-test: 33.8384 clang-import-test: 20.6708 c-index-test: 19.8632 verify-uselistorder: 2.84348 vedant

> On 2014-Jul-30, at 18:05, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2014-Jul-30, at 17:19, Reid Kleckner <rnk at google.com> wrote: >> >>> On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> Looking a little deeper, it's not "old-style" exactly; rejecting this

> On 2014-Jul-31, at 10:07, Reid Kleckner <rnk at google.com> wrote: > >> On Thu, Jul 31, 2014 at 9:49 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> Hold on, I'm still not sure what kind of guarantees (restrictions) the C >> API imposes. >> >> If I implement (2), then -verify will fail if someone (e.g.) adds >>

+reid, +llvmdev, -llvm-commits > On 2014-Jul-30, at 11:56, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > >> I think the fix is to upgrade old-style global arrays (or reject >> them?) in the .ll parser. >> > > The .ll format is not stable, so you should be able to just reject it. Looking a little deeper, it's not

On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Looking a little deeper, it's not "old-style" exactly; rejecting this > > isn't trivial. > > > > - According to LangRef, the third field is optional [1]. > > > > [1]: > http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable

...Users. Some sort of guiding light documentation or source comments that explain what the analysis is supposed to be doing seem to be missing. For example, the following IR will produce different sets of IV users if either: i) The order of the PHI nodes in the %loop block are reordered; or ii) The uselistorder directive is uncommented --- target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" define void @test(i64 %v1, i32 %v2, i64* %addr) { entry: br label %loop loop: %iv = phi i64 [%v1, %entry], [%iv.inc, %loop] %iv2 = phi i...

Pete Cooper and I have been looking at memory profiles of running llc on verify-uselistorder.lto.opt.bc (ld -save-temps dump just before CodeGen of building verify-uselistorder with -flto -g). I've attached leak-backend.patch, which we're using to make Intrustruments more accurate (instead of effectively leaking things onto BumpPtrAllocators, really leak them with malloc()). (I...

...ing between the LTO optimization pipeline and the LTO codegen pipeline. On SPEC, serializing to/from bitcode will change the output executable in 33 benchmarks. If you use `-preserve-bc-use-list-order`, all executables match. How? ==== Have a look at `BitcodeReader::ParseUseLists()` and `predictUseListOrder()` in `lib/Bitcode/Writer/ValueEnumerator.cpp`. Does it degrade smoothly if IR changes? ======================================= Yes. If a `Value`'s use-list has changed in size (e.g., because of bitcode upgrades), its use-list order record is ignored. What does it cost? ==================...

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > > > Not sure I follow? Generally LTO inputs are going to be "user provided" > (in the sense that they're not produced immediately prior by the same > process - or you'd have just produced a single Module in the first place, I > would imagine) so changing the default

...This would explain why text files are not affected: the symbols are used directly in text form so there is no need for this table. I suppose that settles the question of where. Out of curiosity, I'd like to know if there is a way to order the table in a canonical form. I found -preserve-bc-uselistorder which makes more sense (and seems to correspond because the table lists all uses of each symbol), but no luck yet. At least now I'm sure that there is no semantic difference between the programs so it's a great help. :D Thanks, Sébastien Michelland On 5/27/19 1:48 PM, Mehdi AMINI wrot...

...ting section of the bytecode file is likely not a permutation because the byte patterns don't match (some of the btte values of stress-1.bc are not present in stress-2.bc). Thanks for your help :) Sébastien Michelland On 5/24/19 5:32 PM, Eli Friedman wrote: > 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...

...Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For example, the following IR will produce different sets of IV users if either: i) The order of the PHI nodes in the %loop block are reordered; or ii) The uselistorder directive is uncommented --- target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" define void @test(i64 %v1, i32 %v2, i64* %addr) { entry: br label %loop loop: %iv = phi i64 [%v1, %entry], [%iv.inc, %loop] %iv2 = phi i...

...ould have saved over a hundred megabytes in uncompressed space > for macOS users: > > Binary name | Size in megabytes > -------------------------------------------- > clang-check: 54.6725 > llvm-c-test: 33.8384 > clang-import-test: 20.6708 > c-index-test: 19.8632 > verify-uselistorder: 2.84348 > > vedant > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...ould have saved over a hundred megabytes in uncompressed space > for macOS users: > > Binary name | Size in megabytes > -------------------------------------------- > clang-check: 54.6725 > llvm-c-test: 33.8384 > clang-import-test: 20.6708 > c-index-test: 19.8632 > verify-uselistorder: 2.84348 > > vedant > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...ample00 438M pp-trace 434M diagtool 184M llvm-cfi-verify 170M llvm-objdump 168M sancov 158M llvm-rtdyld 149M llvm-ar 148M llvm-nm 145M llvm-extract 145M llvm-link 142M llvm-dwarfdump 141M llvm-split 131M llvm-mc 127M llvm-pdbutil 126M clang-offload-bundler 122M llvm-mca 121M verify-uselistorder 121M llvm-cat 120M llvm-as 117M llvm-special-case-list-fuzzer 117M llvm-demangle-fuzzer 116M llvm-modextract 114M obj2yaml 112M llvm-xray 105M sanstats 105M llvm-symbolizer 96M llvm-readobj 93M llvm-cov 90M lli-child-target 86M llvm-cxxdump 85M llvm-objcopy 83M llvm-cvtres 82...

...we should still run it > at (1). But I don't think we need to run it at (2) and (3). Maybe we > agree on this? > > I agree. The last two in debug mode perhaps? -eric > Someone asked elsewhere in the thread about numbers: I had a look at a > CPU profile (for linking verify-uselistorder with debug info). For > this (not-necessarily-representative) sample, (1) takes 1.6% of ld64 > runtime, and (2) and (3) combined take 3.2% of ld64 runtime. Total of > 4.8%. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm....

...Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/13/2017 01:01 PM, Daniel Neilson via llvm-dev wrote: … snip For example, the following IR will produce different sets of IV users if either: i) The order of the PHI nodes in the %loop block are reordered; or ii) The uselistorder directive is uncommented --- target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" define void @test(i64 %v1, i32 %v2, i64* %addr) { entry: br label %loop loop: %iv = phi i64 [%v1, %entry], [%iv.inc, %loop] %iv2 = phi i...

...-dev wrote: >>> >>> … snip >>> >>>>> For example, the following IR will produce different sets of IV >>>>> users if either: >>>>> i) The order of the PHI nodes in the %loop block are reordered; or >>>>> ii) The uselistorder directive is uncommented >>>>> >>>>> --- >>>>> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1" >>>>> target triple = "x86_64-unknown-linux-gnu" >>>>> >>>>> define void @tes...

...llvm-objdump > 168M sancov > 158M llvm-rtdyld > 149M llvm-ar > 148M llvm-nm > 145M llvm-extract > 145M llvm-link > 142M llvm-dwarfdump > 141M llvm-split > 131M llvm-mc > 127M llvm-pdbutil > 126M clang-offload-bundler > 122M llvm-mca > 121M verify-uselistorder > 121M llvm-cat > 120M llvm-as > 117M llvm-special-case-list-fuzzer > 117M llvm-demangle-fuzzer > 116M llvm-modextract > 114M obj2yaml > 112M llvm-xray > 105M sanstats > 105M llvm-symbolizer > 96M llvm-readobj > 93M llvm-cov > 90M lli-child-target...