similar to: Bug in use-list order serialization

A while back I finished up some work [1] that Chad started to preserve use-list-order in bitcode [2], hidden behind an "experimental" option called `-preserve-bc-use-list-order`. I then added a similar `-preserve-ll-use-list-order` option for LLVM assembly [3]. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074604.html [2]: https://llvm.org/bugs/show_bug.cgi?id=5680 [3]:

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

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

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

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

Ok, I got a strange case.. I got a bugreport from a user about my application crashing on him. After a bit of trouble, I got him to report back the module and offset it crashed at (win32). I always retain a copy of my symbol files for my release builds, so tracking down the crash address leads to: (gdb) list *0x6d5c2213 0x6d5c2213 is in split_cb_search_shape_sign (cb_search.c:414). 409

Dear all, after recently updating my R-packages I am unable to work with lme4, since it does not load. What I get is this: Error in inDL(x, as.logical(local), as.logical(now), ...) : function 'cholmod_l_start' not provided by package 'Matrix' In addition: Warning messages: 1: package 'lme4' was built under R version 2.8.1 2: package 'lattice' was built under R

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

Hello R, To analyze multi-level data, I started learning and using lmer. So far so wonderful. I then found some useful functions in package languageR. But then the following problem ocurred: Whenever I load and use the languageR package, then save the workspace - or quit R with saving the workspace - I am unable to reload that workspace in a later session. That is, R doesn't start at all

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

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

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

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

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

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

Hey guys, I'm a bit of a beginner (understatement!) with shell scripting and seek help! I am setting up our new squid proxy. Its working a treat and squidGuard is the icing on the cake. But, I am trying to write a shell script to search through our black list category's for squidGuard and remove the parsed value; Scenario: /some/directory/where/blacklist/is/stored contains about 40-50

On Mon, Aug 31, 2015 at 11:44 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Aug-31, at 11:41, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > 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

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

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