similar to: [LLVMdev] slooow compiles

My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened

As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: http://blog.regehr.org/extra_files/souper-jul-15.html My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are a number of gems hiding in there that are worth implementing. Blog post containing

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

...if I truss the smbd for such a slow connection I get a mess of smb messages being exchanged prior to the requested browsing information. On a quick WindowsXP connection's truss I do not see any of this "pre-dialogue". I have not a glue. Thanks for any help. Roman __________________________________________________________________ The NEW Netscape 7.0 browser is now available.

Hello, My samba server uses winbind and contains a [homes] section for the active directory users logging into the domain. Each user profile is pointing to the samba server for its "home directory" When XP clients login however, moving around the desktop is extremely slow, (after double clicking my computer, one has to wait 30 seconds or more) It seems to be attributed to the

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

Hi, LLVMers, has someone implemented bitwidth analysis for LLVM? I was looking for something similar to the bitwise compiler described in "Bidwidth analysis with application to silicon compilation, by Mark Stephenson, Jonathan Babb and Saman Amarasinghe" e.g.: http://portal.acm.org/citation.cfm?id=349299.349317 all the best, Fernando

We have some results that are somewhat entertaining and that relate to the size/speed discussion. The basic idea is exhaustive generation of C functions where "exhaustive" is qualified by some structural restrictions (depth of AST, node type, etc.). For one particular set of restrictions we ended up with about 7 million C functions. We then compiled each of these functions with 7

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to

We have a bitwidth analysis that can be downloaded. It is not in LLVM. There should be a link in the paper: http://www.cs.utah.edu/~regehr/papers/pldi075-cooprider.pdf John Regehr

http://www.cs.utah.edu/~regehr/compiler_correctness/llvm_gcc_x86/ I think these graphs speak for themselves. Feedback is welcome. John Regehr

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

I get the error below (and have for a couple weeks now) when trying to build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, everything has been building fine. Both are release builds for x86. John cc1: StringMap.cpp:177: void llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == V2 && "Didn't find key?"' failed.

Hi folks, I've posted an updated code size comparison between LLVM, GCC, and others here: http://embed.cs.utah.edu/embarrassing/ New in this version: - much larger collection of harvested functions: more than 360,000 - bug fixes and UI improvements - added the x86 Open64 compiler John

Unfortunately, the data in the paper doesn't show that, through no fault of the authors :-(. It might be nice to add a qualification and a pointer to this graph along with the paper, if John doesn't object. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Nov 18, 2008, at 12:33 PM, Chris Lattner wrote: > >

> I am having the same problem. It was "introduced" by revision 54811, > so it looks like a memory corruption problem. Investigating. Interesting. Bootstrapping with gcac works! Some tests with valgrind also work. My next try is to add some debug code to do bounds checking in SmallVector. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 |