similar to: llvm PatternMatch Geps?

On Mon, Jul 22, 2013 at 10:19 AM, Stephen Lin <swlin at post.harvard.edu> wrote: > Hi, > > I noticed that ConstantFP::get automatically returns the appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e.,

On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > The computation of %base then becomes loop-invariant and can be lifted out. > > What's the best way to add this optimization to LLVM? Probably the best place is LICM itself... only loop transformations are aware whether something is loop-invariant. Although, I'm not completely

----- Original Message ----- > From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > To: "Hal J. Finkel" <hfinkel at anl.gov>, "Eli Friedman" > <eli.friedman at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Richard Smith" > <richard-llvm at metafoo.co.uk> > Sent: Tuesday, July 26,

Sent from my Verizon Wireless 4G LTE DROID On Jul 25, 2016 6:10 PM, Eli Friedman <eli.friedman at gmail.com<mailto:eli.friedman at gmail.com>> wrote: > > On Mon, Jul 25, 2016 at 2:06 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> ________________________________ >>> >>>

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Friday, February 7, 2020 3:00 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > > On Feb 7, 2020, at 12:39 PM, Eli Friedman

On Feb 9, 2012, at 1:22 PM, Duncan Sands wrote: > Hi Chris, this was a very tempting commit to make, unfortunately it broke > pattern matching of vectors of booleans. The problem is that a > ConstantDataVector is only formed if the element type is one of i8, i16, etc. > So vectors of funky types, or not so funky types like i1, are no longer > matched. I noticed this while working

Hi Chris, >> Hi Chris, this was a very tempting commit to make, unfortunately it broke >> pattern matching of vectors of booleans. The problem is that a >> ConstantDataVector is only formed if the element type is one of i8, i16, etc. >> So vectors of funky types, or not so funky types like i1, are no longer >> matched. I noticed this while working on PR11948. The

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > >

On 30-Jan-09, at 6:14 PM, Eli Friedman wrote: > On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit > <stefanus.dutoit at rapidmind.com> wrote: >> The computation of %base then becomes loop-invariant and can be >> lifted out. >> >> What's the best way to add this optimization to LLVM? > > Probably the best place is LICM itself... only loop

Hi Hal, Thanks for your comments! I'm inlining my responses below. Jingyue On Sat, Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Jingyue, > > I can't speak for the NVPTX backend, but I think this looks useful as an > (optional) target-independent pass. A few thoughts: > > - Running GVN tends to be pretty expensive; have you tried EarlyCSE

Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes

> Yes: > > %array$str = type { i64, [0 x %str] } > > declare i8* @malloc(i64) > > define i64 @foo(i64 %objsz) { > %array.raw = call i8* @malloc(i64 %objsz); > %array = bitcast i8* %array.raw to %array$str* > %array.data = getelementptr %array$str* %array, i32 0, i32 1 > %ret = ptrtoint [0 x %str]* %array.data to i64 > ret i64 %ret > } >

----- Original Message ----- > From: "Vladimir Guzma" <vladimir.guzma at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, February

Thank you you answer. On Sun, May 10, 2009 at 12:48 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Sat, May 9, 2009 at 8:37 AM, Rotem Varon <varonrotem at gmail.com> wrote: > > Its not x86 IR nor x86 assembly. I have x86 IR "like" instructions ( add > > R1, R2, R3 and so...) > >> > >> If it's really > >> x86

>> In this function, the `this` pointer is not pointing at an Operator >> object. That's undefined behavior, right? > > Yes. Well then I guess the next step is how to fix it. Maybe someone with a bit more experience with the Operator code and how it is used could make a suggestion? (I just stumbled upon this code yesterday while doing some refactoring, so I'm not

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

On 4/19/2018 11:57 AM, Friedman, Eli via cfe-dev wrote: > On 4/19/2018 11:48 AM, Manoj Gupta via llvm-dev wrote: >> On Wed, Apr 18, 2018 at 12:54 PM Tim Northover >> <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com>> wrote: >> >> >> On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli >> <efriedma at codeaurora.org

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Wednesday, February 5, 2020 4:02 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > On Jan 29, 2020, at 4:48 PM, Eli Friedman via

I have a question about the pattern matching stuff that's used in the Instruction Combiner. If I have code like this: if (match(B, m_Select(m_Value(), m_ConstantInt(0), m_ConstantInt(-1)))) { if (match(C, m_Not(m_Value(B)))) return SelectInst::Create(cast<User>(B)->getOperand(0), D, A); and we match, the program fails during the