similar to: [LLVMdev] LSR is Unbearably Slow

I also noticed LSR spending a lot of time in GenerateAllReuseFormulae, just to have some cases pruned in NarrowSearchSpaceUsingHeuristics. I'm not familiar enough with the code to comment on how this affects the quality of LSR results, but a hack is to "EstimateSearchSpaceComplexity" inside the loops of GenerateAllReuseFormulae and cut out early. - Jan On Wed, Aug 11, 2010 at 2:48

Unfortunately I still have yet to successfully install llvm. On Wed, May 6, 2009 at 2:32 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > That's correct. Since you have everything linked as shared libraries > system dynamic linker will pick the shared library installed in the > default library location. Most probably you will need to edit > /etc/ld.so.conf and

Hi, > $ make -j15 do you really have 15 CPUs? If not, this will most likely just slow things down. > cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: > bool<unnamed>::SCEVComplexityCompare::operator()(const llvm::SCEV*, > const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' > failed. >

On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the “indvars” pass only takes 45 seconds. > > It seems that the majority of the time is

After using Wine without any significant hitches for over a year, I've just come across one. Every time I load any application (even winecfg), it takes between thirty seconds to one minute for it to load. During this time, normal functions take forever or don't work at all (selecting folders, opening a file, etc.). Sometimes it will load and work just fine, but often the program continues

On Tue, Jul 30, 2013 at 2:20 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > > Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the > attached IR.) Creating SCEVs for these expressions takes a long time, making > the compile time too long. E.g., running

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

Hi Andy, Thanks very much for looking into the problem. In this particular test case, it seems most of the time is spent in the sorting, not the grouping. Later, I realized that it seems in this test case most of the expressions to be compared have different length. I tried the following change in compare() when the LHS and RHS's types are the same:

Hello, Scott > Yes, so I have read -- which is why I initially installed gcc-4.2.4. > My original post was looking for help on how to use gcc-4.2.4. Some > suggestions were made, but I was not able to get everything built. It > seems that despite attempting to configure with everything pointing to > gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, >

>> $ make -j15 > > do you really have 15 CPUs?  If not, this will most > likely just slow things down. > I have 8 CPUs. I started with -j8 and turned the knob up a bit. It seemed to run faster, so I stuck with j15. I guess there might be some context switching when threads are blocking on memory or IO. I could be imagining the speedups though because of some sort of placebo

On Wed, May 6, 2009 at 12:51 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Even if you'll succeed, most probably LLVM will be miscompiled. gcc > 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc > Yes, so I have read -- which is why I initially installed gcc-4.2.4. My original post was looking for help on how to use gcc-4.2.4. Some

Hi, We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the "indvars" pass only takes 45 seconds. It seems that the majority of the time is spent in comparing the complexity of the expression operands to sort them. I realize that the

I have a few questions regarding cost calculation in loop strength reduction. 1. Ignoring LSR uses of kind ICmpZero. These usually come from the loop latch conditions. On Hexagon most loops that would contain such a LSR use are going to be converted to hardware loops and the entire check will disappear. There is no need to analyze these cases in LSR. In fact, completely ignoring them improves

Hi Geoff, Thanks for the detailed reproduction instruction -- they were very helpful, and I can now see the bug. Generally, I think (2) is the better solution. It should be up to SCEVExpander to keep its state consistent. The fact that we're trying to optimize instructions as we insert them makes that trickier, but I still think that is the right invariant to have. I don't see why (2)

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 1:40:24 PM > Subject: [LLVMdev] LSR pass > > > > > > Hi, > > > > I would like some help regarding the LSR pass. It seems that it likes > to duplicate address calculations as in the

Hi, The target supports indexing by register or immediate. Multiplications are not supported by any load / store instructions. Would it be possible to make LSR aware of this? Thanks, Jonas Paulsson -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, December 01, 2012 5:59 AM To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LSR pass

In an effort to turn on the new pass manager by default, I've been trying to make all lit tests pass when opt uses the new pass manager. (Change the default value of -enable-new-pm in opt.cpp to true to repro) A good chunk of the remaining failures are some loop pass tests, mostly LSR, that are failing. The legacy PM does not by default run LCSSA before running loop passes, but the new PM

Hi, I find that LSR is not helping enough on avoiding unfoldable offsets for SystemZ. When the loop has three stores with unfoldable offsets, LSR rewrites the IV in a good way. However, if adding another store with a foldable offset that fits already, LSR fails to rewrite the three stores. And if I happen to add a too big *positive* offset (the first three were negative) instead of a

Dear all, From what I can gather, there is currently no way for loop strength reduction to target pre- and post-increment addressing modes. This is because the target hook `isLegalAddressingMode` in TargetTransformInfo.h doesn’t allow for pre- and post-increment. There is in fact a comment to that effect on the function prototype: “TODO: handle pre/postinc as well” (see

Hi Geoff, Firstly, I think it will be great if you have a small reproducer of this issue (which I can make fail after re-applying D18001 to ToT). > I’ve run into what appears to be a bug in ScalarEvolution, but I’m not sure > if it is instead caused by me missing an implicit assumption between LSR and > SCEV. > > This issue is caused by the change D18001, which is an attempt to