similar to: [LLVMdev] ISel Pattern Preferences

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.

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

Not yet. http://wiki.llvm.org On Tue, Apr 7, 2009 at 6:06 PM, David Greene <dag at cray.com> wrote: > 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 >

On Aug 11, 2013, at 4:14 AM, "Nuno Lopes" <nunoplopes at sapo.pt> wrote: >> This sounds promising. But we have some requirements that textbook rewriting systems can't handle: >> >> - Expressions are DAGs, not trees. >> - Targets can add custom rewriting rules and override standard rules. >> - Rules will have predicates. Some predicates are static

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

>>> I like the idea of sharing code between IR and MI passes through an >>> abstract interface. I think that later stages in the IR pipeline also >>> need an instruction optimizer instead of a canonicalizer. >>> >>> An alternative approach would be to describe these transformations in a >>> DSL instead of C++. >> >>>

On Apr 7, 2009, at 9:03 AM, someguy wrote: > Not yet. > > http://wiki.llvm.org I added a link to the sidebar. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090407/bd8eb148/attachment.html>

Thanks Chris! Can we put it in the IRC channel's topic as well? On Tue, Apr 7, 2009 at 7:35 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 7, 2009, at 9:03 AM, someguy wrote: > > Not yet. > http://wiki.llvm.org > > > I added a link to the sidebar. > > -Chris > > > _______________________________________________ > LLVM Developers

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 Aug 10, 2013, at 7:32 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> I like the idea of sharing code between IR and MI passes through an abstract interface. I think that later stages in the IR pipeline also need an instruction optimizer instead of a canonicalizer. >> >> An alternative approach would be to describe these transformations in a DSL instead of C++. >

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

Hi, I'd like to understand the order in which patterns are searched during ISEL. In the example below, indices are searched in ascending order from 808 to 3305, then it goes back to 3259 and eventually it matches the wrong instruction. Why did go back from 3305 to 3259? In my XXXGenDAGISel.inc, I can see that the correct instruction is at index 3420 but it never got there. ISEL: Starting

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

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.

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

On Thursday 02 October 2008 11:37, David Greene wrote: > I'll try ot write a small example and send it in a bit. Ok, here's what I'm trying to do: let AddedComplexity = 40 in { def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr: $src1))), (v2f64 (scalar_to_vector (loadf64 addr: $src2))),

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this

On Oct 7, 2008, at 12:04 PM, David Greene wrote: > 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

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.