similar to: [LLVMdev] [RFC] Setting preserve-bc-use-list-order=true by default

> On 2015-Apr-09, at 11:06, David Blaikie <dblaikie at gmail.com> wrote: > > Late to the party because I figured other people would chime in, but I'll have a go... > > On Tue, Mar 31, 2015 at 7:10 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > A while back I finished up some work [1] that Chad started to preserve > use-list-order in bitcode

> On 2015-Apr-10, at 09:12, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Apr 9, 2015 at 12:37 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015-Apr-09, at 11:06, David Blaikie <dblaikie at gmail.com> wrote: > > > > Late to the party because I figured other people would chime in, but I'll have a

Should the binaries included in an LLVM release be generally useful to a wide audience of toolchain users, or is it OK to ship tools that are only really useful for LLVM development? If the former is the case, can we consider not shipping tools which are exclusively for testing the compiler? E.g removing these 5 binaries from 5.0.2-rc1 would have saved over a hundred megabytes in uncompressed

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

Hi all, I’ve most recently been grappling with a difficult to reproduce bug. I’ve traced the source of the difficulty in reproduction to the IVUsers analysis pass that is used by Loop Strength Reduction. Specifically, the IVUsers pass’s output is very sensitive to both the use list ordering of the instructions that it is looking at and the ordering of the Phi nodes in the header block of the loop

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've

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

Hi Eli, Unfortunately the differences remain, I do not observe a significant change in the output besides the fact that it's random. I noticed that running opt without options on the random file changes the order of references in the predecessors of basic blocks (sample below). Further invocations of opt are idempotent. I don't know of this information is stored in the bytecode file

Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal 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

Dear llvm developpers, I followed the tutorial to build llvm and clang provided here: https://clang.llvm.org/get_started.html The sources are in sync with subversion repository, and I ended up with more than 30GB of binaries in llvm/bin as shown at the end of this message. I assume I did something wrong, but I did not find any entry in the doc that helps me understand how to reduce the size of

On Mon, Aug 31, 2015 at 11:40 AM Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Aug-31, at 10:42, Reid Kleckner <rnk at google.com> wrote: > > > > 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

Hi Mehdi, Thank you for mentioning this tool, I was looking for something like this. By default the analyzer produces identical output on both files, but a complete -dump shows that the storage order of the symbol table is different. 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

On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: On 09/14/2017 10:43 AM, Daniel Neilson wrote: Thank you for your thoughts, Hal. More information below... On Sep 13, 2017, at 5:43 PM, Hal 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

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 |

Hi, I've stumbled upon a case where I think gvn does a bad (wrong) optimization. It's a bit messy to debug though so I'm not sure if I should just write a PR about it a let someone who knows the code look at it instead. Anyway, for the bug to trigger I need to run the following passes in the same opt invocation: -sroa -instcombine -simplifycfg -instcombine -gvn The problem

Please keep llvm-symbolizer in the install distribution. If a user's program crashes then I like to print out a backtrace with file name/line number if compiled with debug. Forking off llvm-symbolizer is the easiest way for me to obtain the debug information. Thanks. On Mon, May 14, 2018 at 5:27 PM, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Should the

A new one was just added recently - Clang's diagtool. So if you're looking at how to reduce install size, might want to double check that the motivation for adding that is consistent with/not contradictory with your goals/motivations for removing these. (also since several of these are clang binaries/tools - maybe check with the cfe-dev list too) On Mon, May 14, 2018 at 2:27 PM Vedant

On 09/14/2017 10:31 PM, Daniel Neilson wrote: > > >> On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 09/14/2017 10:43 AM, Daniel Neilson wrote: >>> Thank you for your thoughts, Hal. More information below... >>> >>>> On Sep 13, 2017, at 5:43 PM, Hal Finkel

On Fri, Apr 27, 2018 at 6:21 PM, Manuel Yguel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Dear llvm developpers, > I followed the tutorial to build llvm and clang provided here: > https://clang.llvm.org/get_started.html > > The sources are in sync with subversion repository, and I ended up with more > than 30GB of binaries in llvm/bin as shown at the end of this

I need to track down all pointers anywhere in a module that could be pointing to functions (because some of the optimizations I want to do, require either identifying every use of a function, or conservatively identifying when such cannot be done). A starting point is to look at all the global variables: for (auto &G : M.globals()) for (auto &V : G.operands()) if (auto F =