search for: newmask

Hi all, I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug: if (Mask[i] >= 2*e) NewMask.push_back(2*e); else NewMask.push_back(LHSMask[Mask[i]]); When Mask[i] is bigger than the size of LHSMask it reads out of bounds on that last line. I believe the first line is there to try to prevent that but then it should be comparing to LHSMask.size() not 2*e (e being Mask.size()). And...

...16:31 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine Hi Nicolas, On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug: if (Mask[i] >= 2*e) NewMask.push_back(2*e); else NewMask.push_back(LHSMask[Mask[i]]); When Mask[i] is bigger than the size of LHSMask it reads out of bounds on that last line. I believe the first line is there to try to prevent that but then it should be comparing to LHSMask.size() not 2*e (e being Mask.size())....

...use knowledge about the RHS to // simplify the LHS, here we're using information from the LHS to simplify // the RHS. if (ConstantSDNode *RHSC = dyn_cast<ConstantSDNode>(Op.getOperand(1))) { APInt LHSZero, LHSOne; TLO.DAG.ComputeMaskedBits(Op.getOperand(0), NewMask, LHSZero, LHSOne, Depth+1); // If the LHS already has zeros where RHSC does, this and is dead. if ((LHSZero & NewMask) == (~RHSC->getAPIntValue() & NewMask)) return TLO.CombineTo(Op, Op.getOperand(0)); As neither of these are virtual...

Hi Nicolas, On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: > I’m having some trouble understanding the following lines in > InstructionCombining.cpp, which possibly contain a bug: > > if (Mask[i] >= 2*e) > NewMask.push_back(2*e); > else > NewMask.push_back(LHSMask[Mask[i]]); > > When Mask[i] is bigger than the size of LHSMask it reads out of > bounds on that last line. I believe the first line is there to try > to prevent that but then it should be comparing to LHSMask.size() >...

Hi! Is there a pass that optimizes vector operations? If I have for examle a sequence of shufflevector instructions that optimizes them? (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) -Jochen

Instcombine does of this, late codegen also does some of it. -Chris On May 14, 2010, at 5:58 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > Is there a pass that optimizes vector operations? > If I have for examle a sequence of shufflevector instructions > that optimizes them? > (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) > > -Jochen

...16:31 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine Hi Nicolas, On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug: if (Mask[i] >= 2*e) NewMask.push_back(2*e); else NewMask.push_back(LHSMask[Mask[i]]); When Mask[i] is bigger than the size of LHSMask it reads out of bounds on that last line. I believe the first line is there to try to prevent that but then it should be comparing to LHSMask.size() not 2*e (e being Mask.size())....

...List > Subject: Re: [LLVMdev] Shuffle combine > > Hi Nicolas, > > On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: > I’m having some trouble understanding the following lines in > InstructionCombining.cpp, which possibly contain a bug: > > if (Mask[i] >= 2*e) > NewMask.push_back(2*e); > else > NewMask.push_back(LHSMask[Mask[i]]); > > When Mask[i] is bigger than the size of LHSMask it reads out of > bounds on that last line. I believe the first line is there to try > to prevent that but then it should be comparing to LHSMask.size() >...

...o > // simplify the LHS, here we're using information from the LHS to > simplify > // the RHS. > if (ConstantSDNode *RHSC = > dyn_cast<ConstantSDNode>(Op.getOperand(1))) { > APInt LHSZero, LHSOne; > TLO.DAG.ComputeMaskedBits(Op.getOperand(0), NewMask, > LHSZero, LHSOne, Depth+1); > // If the LHS already has zeros where RHSC does, this and is dead. > if ((LHSZero & NewMask) == (~RHSC->getAPIntValue() & NewMask)) > return TLO.CombineTo(Op, Op.getOperand(0)); > > > &...

...List > Subject: Re: [LLVMdev] Shuffle combine > > Hi Nicolas, > > On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: > I’m having some trouble understanding the following lines in > InstructionCombining.cpp, which possibly contain a bug: > > if (Mask[i] >= 2*e) > NewMask.push_back(2*e); > else > NewMask.push_back(LHSMask[Mask[i]]); > > When Mask[i] is bigger than the size of LHSMask it reads out of > bounds on that last line. I believe the first line is there to try > to prevent that but then it should be comparing to LHSMask.size() >...

...romoted. Therefore I have wanted to keep the 'and' to make correct 1 bit value. But dag combine pass is removing the 'and' on TargetLowering::SimplifyDemandedBits function. When I look at the function, even though the LHS does not have knownbit information, the code uses it with NewMask to compare LHS with RHS. Is it intended? Could someone explain it? If I missed something, please let me know. Thanks, JinGu Kang

...k.lshr(offset * (width/8) * 8); - bestWidth = width; + EVT NewVT = EVT::getIntegerVT(*DAG.getContext(), width); + if (isNarrowingProfitable(Lod->getMemoryVT(), NewVT)) + bestWidth = width; break; } newMask = newMask << width;

Philip Reames <listmail at philipreames.com> writes: > Question 1 - Why do we need separate mask and lengths? Can't the > length be easily folded into the mask operand? > > e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1)) > and then pattern matched in the backend if needed I'm a little concerned about how difficult it will be to maintain enough information throughout compilation to be able to match this on a machine with an explicit vector length value. &g...

...gt; > On 1/31/19 11:03 AM, David Greene wrote: >> Philip Reames <listmail at philipreames.com> writes: >> >>> Question 1 - Why do we need separate mask and lengths? Can't the >>> length be easily folded into the mask operand? >>> >>> e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1)) >>> and then pattern matched in the backend if needed >> I'm a little concerned about how difficult it will be to maintain enough >> information throughout compilation to be able to match this on a machine >> with an...

On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >> >>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>> >>>> Our architecture has 1-bit boolean predicate registers. >>>> >>>> I've defined comparison >>>> >>>> def

...t; On 1/31/19 11:03 AM, David Greene wrote: > > Philip Reames <listmail at philipreames.com> writes: > > > >> Question 1 - Why do we need separate mask and lengths? Can't the > >> length be easily folded into the mask operand? > >> > >> e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1)) > >> and then pattern matched in the backend if needed > > I'm a little concerned about how difficult it will be to maintain enough > > information throughout compilation to be able to match this on a machine > > wit...

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy

...11:03 AM, David Greene wrote: > Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> writes: > >> Question 1 - Why do we need separate mask and lengths? Can't the >> length be easily folded into the mask operand? >> >> e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1)) >> and then pattern matched in the backend if needed > I'm a little concerned about how difficult it will be to maintain enough > information throughout compilation to be able to match this on a machine > with an explicit vector...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more