similar to: [LLVMdev] pattern matching order

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Feb 8, 2013, at 9:38 AM, Reed Kotler <rkotler at mips.com> wrote: > >> It seems that patterns are matched in the order that they appear in the td file. >> Is this something we can rely on? > > It is by design but it is the last resort for ordering, and it is very fragile to depend on that. > > It is

On Feb 8, 2013, at 9:38 AM, Reed Kotler <rkotler at mips.com> wrote: > It seems that patterns are matched in the order that they appear in the td file. > > Is this something we can rely on? It is by design but it is the last resort for ordering, and it is very fragile to depend on that. It is better to use AddedComplexity to control pattern ordering when required. /jakob

What's a reliable way to prefer one patterns over another? I have two patterns with different predicates. Pattern A has a very general predicate to catch a wide variety of store instructions. Pattern B has a narrower predicate meant to catch very specific store instructions that would also satisfy the predicate for Pattern A. We used to match Pattern B just fine but after changing .td

On Monday 06 April 2009 13:31, David Greene wrote: > What's a reliable way to prefer one patterns over another? I have two > patterns with different predicates. Pattern A has a very general predicate > to catch a wide variety of store instructions. Pattern B has a narrower > predicate meant to catch very specific store instructions that would also > satisfy the predicate for

David, Would you mind documenting what you did with AddedComplexity for the 'less fortunate' on the wiki? Thanks, Justin. On Mon, Apr 6, 2009 at 9:47 PM, David Greene <dag at cray.com> wrote: > On Monday 06 April 2009 13:31, David Greene wrote: > > What's a reliable way to prefer one patterns over another? I have two > > patterns with different predicates.

I'm getting this error in my mips16 port. I think that PHI replacement is done in some target independent phase. In the process of debugging this. Maybe to someone else it's obvious how this can happen . tia, Reed *** Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor! *** - function: main - basic block: BB#0 entry

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

On Tuesday 07 April 2009 01:20, someguy wrote: > David, > Would you mind documenting what you did with AddedComplexity for the 'less > fortunate' on the wiki? Yep. Will do. Hmm...is there a link to the Wiki on the main page? I can't find it. -Dave

It does have an output register, it's just an implicit flag register. It still has a DAG output. I'm not sure if the allocatable bit matters at this point for selection purposes, but it does later. Not adding a type to the register class can also be problematic (e.g. a flag register should have i1 added to regTypes for its class). -Matt > Does LLVM make an assumption that there is an

A better way to handle this is to a td pattern to match "add n, -c" to a subtraction. I believe several targets do something similar to this. Evan On May 16, 2013, at 7:12 AM, Tom Stellard <tom at stellard.net> wrote: > On Thu, May 16, 2013 at 02:03:14AM +0000, Martin Filteau wrote: >> Hi all, >> >> It's the first LLVM backend we do for our asynchronous

Thanks for swift reply > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hi, >> I'm new to LLVM and I'm doing research on factors of compilation time, >> especially instruction

On Fri, Feb 19, 2016 at 6:10 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/18/2016 6:01 PM, Rail Shafigulin via llvm-dev wrote: > >> [(set SR:$rD, (Esenciasetflag (i32 GPR:$rA), (i32 >> immSExt16:$imm), (i32 Cond)))]> { >> > > I suspect that the "set SR:$rD" is the problem here. The Esenciasetflag

On 3/30/2016 4:42 PM, Rail Shafigulin via llvm-dev wrote: > i'm getting a > > Could not infer all types in pattern! > > error in my backend. it is happening on the following instruction: > > VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} > VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). > > how do i make it use appropriate types? in other words if it is f32 then

On May 1, 2009, at 3:50 PM, Chris Lattner wrote: > > The goal is to replace the pattern fragment and the C++ code for > X86::isMOVDDUPMask with something like: > > def movddup : PatFrag<(ops node:$lhs, node:$rhs), > (vector_shuffle node:$lhs, node:$rhs, > 0, 1, 0, 1, Cost<42>) > > Alternatively, the

Chris Lattner wrote: > On Sep 23, 2008, at 11:26 AM, David Greene wrote: > >> Are there any examples of using tablegen to generate multiple machine >> instructions from a single pattern? Or do these cases always have >> to be >> manually expanded? > > PPC has a bunch of examples, for example: > > // Arbitrary immediate support. Implement in terms of

On Sep 23, 2008, at 7:17 PM, David Greene wrote: > Chris Lattner wrote: >> On Sep 23, 2008, at 11:26 AM, David Greene wrote: >> >>> Are there any examples of using tablegen to generate multiple >>> machine >>> instructions from a single pattern? Or do these cases always have >>> to be >>> manually expanded? >> >> PPC has a

On Friday 03 October 2008 12:06, Dan Gohman wrote: > On Fri, October 3, 2008 9:10 am, David Greene wrote: > > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection > >> loads have multiple uses, so even though you've managed to match a > >> larger pattern that incorporates them, they

On Tue, Jun 28, 2016 at 5:49 AM, Bekket McClane <bekket.mcclane at gmail.com> wrote: > Thanks for swift reply > > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > I'm new to LLVM and I'm doing research on factors

> > > > > def SDTX86CmpPTest : SDTypeProfile<1, 2, [SDTCisVT<0, i32>, > SDTCisVec<1>, > SDTCisSameAs<2, 1>]>; > > This is confusing to me. This tells me that there is 1 result but and 2 > operands. But then it says that operands 2 and 1 are of the same type,

On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,