similar to: IndVarSimplify: getBackedgeTakenCount and Release vs Assert

This might be hard cases making bad law, but the loop: void f (unsigned short *x, int *l) { int c = *l; int i; for (i = 0; i < c; i++) if (x[i]) x[i]++; } is converted to decrement-and-branch form by LoopStrengthReduce while: void f (unsigned short *x, int *l) { int i; for (i = 0; i < *l; i++) if (x[i]) x[i]++; } isn't.

Hi Sanjoy, Thanks for investigating the issue! I am more interested in getting the underlying problem fixed rather than making this particular test case work. I think I have more test cases where this problem crops up. I would any day prefer consistent results over compile time savings which can lead to inconsistencies. These inconsistencies require significant developer time to analyze and fix

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

Thanks Eli, After digging thru mail archives & bugzilla, it seems fixing properly this issue would require a major change in the selectionDAG code --- to have it operate on a per function basis instead of per basic-block. This however, does not seem to be the only issue. The following C code does not produce an efficicient assembly sequence either. extern void f(unsigned long long v); void

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target

2011/11/21 Tobias Grosser <tobias at grosser.es>: > On 11/20/2011 04:36 PM, Marcello Maggioni wrote: >> >> Sorry for the noobish question, but what kind of subscripts generate a >> SCEVCouldNotCompute  from the SCEV engine? >> I tried for a while but I wasn't able to trigger that > > Hi Marcello, > > the SCEV returns SCEVCouldNotCompute in case it

On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > Dear guys, > > I am having problems to obtain good information from the LoopInfo. > I am always getting a trip count of 0, even though I am clearly passing > a loop with a constant bound. I am using this pass below: Hi, I would propose to first check if the trip count is calculated correctly. I would do this with opt

On Thu, Aug 12, 2010 at 5:22 PM, Tobias Grosser <grosser at fim.uni-passau.de>wrote: > On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > >> Dear guys, >> >> I am having problems to obtain good information from the LoopInfo. >> I am always getting a trip count of 0, even though I am clearly passing >> a loop with a constant bound. I am using

Hi, Is it valid to query ScalarEvolution::getSCEVAtScope with a Value which is an Instruction inside the provided Loop? If so, I believe there is a bug in computeSCEVAtScope. Specifically: 04716     // If the scope is outside the addrec's loop, evaluate it by using the 04717     // loop exit value of the addrec. 04718     if (!AddRec->getLoop()->contains(L)) { 04719       // To

Nevermind. I misread the documentation. On Sat, Apr 30, 2011 at 8:12 PM, Thomas Jablin <tjablin at gmail.com> wrote: > Hi, > > Is it valid to query ScalarEvolution::getSCEVAtScope with a Value > which is an Instruction inside the provided Loop? If so, I believe > there is a bug in computeSCEVAtScope. Specifically: > > 04716     // If the scope is outside the

> From: Eric Christopher > Subject: Re: [LLVMdev] How to associate extra comments to a > MachineInstruction ? > > Should be spelled like this yes? > > Asm->OutStreamer.AddComment("foo") > Asm->EmitFoo(); > > -eric That should work at the moment that you are emitting the instructions. But what would you do when you are manipulating a

Ok I think we have some common ground - CSE should choose the aliased pointer over the non-aliased one because we don't want the no-aliasing information to creep outwards from the inlined callsite. I'll put together a patch in the coming days and add y'all as reviewers so you get visibility. Cheers, -Neil. On Wed, Jan 22, 2020 at 4:47 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at

Hi, I am trying to make my tablegen files more flexible and for that I would like to have a name that in the end will be replaced with a type. If tablegen would support c preprocssing, I would do it like this: --- #define myBaseType i32 ... def imm32 : Operand<myBaseType>; def immZExt10 : ImmLeaf<myBaseType, [{return isUInt<10>(Imm);}]>; ... --- Is there a way to achieve

Hi, I am trying to do loop unrolling with loops that don't have constant loop counter. It is highly appreciated if anyone can help me on this. What I want to do is to turn loop (n) { <loop body> } into loop (n/4) { <loop body> <loop body> <loop body> <loop body> } loop (n%4) { <loop

Johannes, Thanks, I have been following along some of the thread(s) and the phab reviews. The scope of this work is more encompassing than our current needs and I've looked at trying to carve a piece out. It's not clear to me what purpose the llvm.noalias intrinsic serves right now. Also, if a mem instruction has !noalias metadata, then it should not be aliased, but I must be missing

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -